[C++] MySQL connectie mislukt

[Dred]

We (ik en m'n groep) proberen al een paar uur een fout weg te werken. We proberen een connectie op te zetten naar een mysql server, niet meer dan dat. Overal op internet zijn daar eenvoudige voorbeeldjes over te vinden, doch slagen wij er niet in een werkende connectie te verkrijgen. Al 100'den malen de project properties overlopen en deze zouden moeten in orde zijn (een ander project met die instellingen doet het wel)

We gebruiken c++ met de mysql c++ connector in de MS Visual Studio IDE

code:

sql::mysql::MySQL_Driver *driver;
sql::Connection *con;
driver = sql::mysql::MySQL_Driver::Instance();
try {
    con = driver->connect("tcp://iets.nogiets.tld:poortje", "xxx", "xxx");
    std::cout << "het is gelukt!";
}catch(std::exception& ex){
    std::cout << ex.what();
}
delete con;

de verkregen error is:
Unhandled exception at 0x00456001 in Beurs.exe: 0xC0000005: Access violation reading location 0x0000000f.

[Wolfboy]

Open je debugger en kijk waar het fout gaat?

De foutmelding lijkt me duidelijk... je krijgt ergens een exception waar je niets mee doet.

[Mijzelf]

Niet dat het je probleem oplost, maar uit je source plus foutmelding kan ik niet opmaken of driver wel een waarde krijgt. Gezien de foutmelding zou het een nullpointer kunnen zijn.

[mocean]

In je andere project maak je daar verbinding met dezelfde server? Ander staat MySQL-toegang van buitenaf (anders dan localhost) misschien uit.

Verder let op, phpmyadmin staat gewoon open he! Kom je daar wel in trouwens met je user/password?

[.oisyn]

Sowieso is je code fout als de connectie mislukt. Want als regel 5 een exception geeft wordt 'con' nooit gezet. Toch delete je 'm op regel 10. Het is dus handiger om con op 0 te initialiseren op regel 2.

Verder met Wolfboy, we kunnen je niet helpen als je niet eerst zelf achterhaalt exact op welke regel de AV optreedt.

[ Voor 3% gewijzigd door .oisyn op 25-11-2009 18:17 ]

[Dred]

Ohja, de verkregen error wordt gesmeten door de driver->connect maar wordt niet opgevangen in het try/catch blok. Ik vind de error nogal redelijk cryptisch (is ook het enige dat we krijgen van melding), dus misschien dat iemand wel meer weet wat dit wil zeggen.

@Mijzelf: Goeie, kijk ik na, maar naar wat ik denk te herinneren uit de debugger staan er nergens nullwaarden bij de variabelen.

@MCOcean: zelfde server (en ondertussen ff weggehaald uit startpost ;-)), meer zelfs, zelfde gebruiker en DB.

@.Oisyn: rekening gehouden met je opmerking ivm con, dus de code ziet er weer wat beter uit (maar nog altijd no luck)

[Zoijar]

Dred schreef op woensdag 25 november 2009 @ 18:24:
Ohja, de verkregen error wordt gesmeten door de driver->connect maar wordt niet opgevangen in het try/catch blok. Ik vind de error nogal redelijk cryptisch (is ook het enige dat we krijgen van melding), dus misschien dat iemand wel meer weet wat dit wil zeggen.

Dan zal het wel geen afgeleide zijn van std::exception. Waarschijnlijk heeft je library zijn eigen exception class. (ik vermoed SqlException) Oh, je bedoelt de access violation, die catch je idd niet zoals oisyn hieronder zegt.

@.Oisyn: rekening gehouden met je opmerking ivm con, dus de code ziet er weer wat beter uit (maar nog altijd no luck)

Ik raad aan iets als std::tr1::shared_ptr<sql::Connection> te gebruiken voor dit soort dingen.

[ Voor 6% gewijzigd door Zoijar op 25-11-2009 18:53 ]

[.oisyn]

Het is een access violation, die kun je idd niet afvangen met een std::exception . Met geen enkele class trouwens, alleen met catch(...)*. Maar die moet je niet eens willen afvangen, die moet je sowieso voorkomen. De code doet gewoon dingen die niet mogen. Ik gok erop dat de driver pointer verkeerd is, danwel dat er een discrepantie zit tussen de header die je gebruikt voor je project en de bijbehorende library.

*Tenzij je wat gaat hacken met SE handlers en 'm wrapt in een C++ class

[ Voor 84% gewijzigd door .oisyn op 25-11-2009 18:51 ]

[Wolfboy]

.oisyn schreef op woensdag 25 november 2009 @ 18:48:
*Tenzij je wat gaat hacken met SE handlers en 'm wrapt in een C++ class

offtopic:
In veel gevallen vind ik "kan niet" de betere uitleg. Zeggen dat het met een lading hackwerk wel kan geeft meestal meer problemen na afloop

[Dred]

Denken met een volle maag gaat beter! Zowaar na het innemen van wat voedsel en het doornemen van de project file van MSVS zag ik nog een klein verschil (2 .lib bestanden in dit project vs enkel mysqlcppconn.lib in het project die wel werkt) En nu krijg ik nog steeds een Access Violation, maar met bruikbaardere informatie.

"Unhandled exception at 0x7855b9f0 (msvcr90.dll) in Beurs.exe: 0xC0000005: Access violation reading location 0xcccccccc."

Deze gaf wel hits op google, en zoals .oisyn al zei hierboven (helderziend?) zou dit kunnen liggen aan de driver variabele/pointer (god, wat is dat c++ gedoe nogal een gedoe )

.oisyn schreef op woensdag 25 november 2009 @ 18:48:
Ik gok erop dat de driver pointer verkeerd is, danwel dat er een discrepantie zit tussen de header die je gebruikt voor je project en de bijbehorende library.

Hoe je die discrepantie oplost zie ik niet direct, maar ik ga alvast proberen met eventjes alles van de mysql connector te deïnstalleren en opnieuw te installeren, er zijn idd een paar .lib's over en weer gekopieerd tussen de pc's, misschien had iemand een andere versie ofzo.

[Dred]

Zo, het was toch iets anders. het is waarschijnlijk niet de mooiste oplossing, maar door ipv de builden met de "debug" config, moet ik builden met de "release" config in MSVS en dan werkt het als een trein. in het testprojectje waar het reeds werkte stond deze stiekem al zo.

Nu kunnen we beginnen de code wat robuster te maken, want zoals jullie al aanhaalden, er kan nog veel verkeerd lopen nu. Hopelijk binnenkort de eerste queries vanuit c++

[Soultaker]

Tenzij het probleem 'm inderdaad zit in librarycompatibiliteit, is de kans groot dat je nu alleen het symptoom (de crash) hebt weggewerkt en niet de oorzaak (de fout in je code). Je delete sowieso een ongeïnitialiseerde pointer als de verbinding faalt.

Als ik jou was zou ik eerder proberen de fout in debug-mode te fixen (zorg ervoor dat de goede library gebruikt wordt als dat het probleem is) in plaats van door te modderen met mogelijk foutieve code. Dat gaat je later nog wel opbreken anders.

[.oisyn]

Bestaan er niet gewoon debug versies van de library waarmee je moet linken in debug mode? Dingen als standaard C++ classes verschillen kwa layout nogal eens in debug tov release in MSVC++, onder het mom van extra veiligheid. Zet eens "_CRT_SECURE_NO_DEPRECATE;_SECURE_SCL=0" (zonder de quotes) in de preprocessor definitions van je project(onder C/C++ -> preprocessor), en probeer het dan eens (in debug mode dus). Als de STL gebruikt wordt ben je sowieso fucked, tenzij je zelf debug versies van de libaries kunt bouwen.

[ Voor 16% gewijzigd door .oisyn op 25-11-2009 21:25 ]

[Soultaker]

Als 't gewoon om de MySQL C++ Connector API gaat is er wel degelijk een debug library. Verder:

Building Windows applications with Microsoft Visual Studio

Note
To avoid potential crashes the build configuration of MySQL Connector/C++ should match the build configuration of the application using it. For example, do not use the release build of MySQL Connector/C++ with a debug build of the client application.

Letterlijk de tweede alinea op die pagina.

[.oisyn]

[Dred]

Is het heel erg als dat allemaal niet zo heel erg goed werkt met die debug dingen? Zo te zien bestaat er inderdaad een debug lib enzo, maar ik geraak er niet goed uit hoe dat dan wel werkt.

Overigens .Oisyn, ik krijg wat rare foutmeldingen als ik jou tip uitprobeer. Mochten jullie echt zeggen dat het een voordeel oplevert hier toch wat meer tijd in te steken (debug libraries enzo), maar anders blijft het zo hoor, het werkt nu...

[.oisyn]

Dred schreef op vrijdag 27 november 2009 @ 10:47:
Is het heel erg als dat allemaal niet zo heel erg goed werkt met die debug dingen? Zo te zien bestaat er inderdaad een debug lib enzo, maar ik geraak er niet goed uit hoe dat dan wel werkt.

Wat werkt er dan niet? Of krijg je dezelfde issues?

Overigens .Oisyn, ik krijg wat rare foutmeldingen als ik jou tip uitprobeer.

Dan zul je het daarmee ook niet oplossen.

[Wolfboy]

Dred schreef op vrijdag 27 november 2009 @ 10:47:
Is het heel erg als dat allemaal niet zo heel erg goed werkt met die debug dingen? Zo te zien bestaat er inderdaad een debug lib enzo, maar ik geraak er niet goed uit hoe dat dan wel werkt.

Overigens .Oisyn, ik krijg wat rare foutmeldingen als ik jou tip uitprobeer. Mochten jullie echt zeggen dat het een voordeel oplevert hier toch wat meer tijd in te steken (debug libraries enzo), maar anders blijft het zo hoor, het werkt nu...

Om dergelijke problemen in de toekomst op te lossen is een debugger wel erg prettig natuurlijk, het scheelt een hoop trial-and-error programmeerwerk. Maar als je toch geen debugger gebruikt heeft het niet heel veel toegevoegde waarde.

[.oisyn]

Hij zegt niet dat ie geen debugger gebruikt, hij zegt dat hij de debug versie van de mysql connector library niet aan de praat kan krijgen. Een release build is ook wel te debuggen, al helemaal als je optimalisaties uitzet.

[ Voor 23% gewijzigd door .oisyn op 27-11-2009 12:14 ]

[Wolfboy]

Daar heb je gelijk in, al zijn debug builds vaak toch een stuk prettiger om mee te werken. Anders zit je al vrij snel in assembler te graven. Maargoed, daarom ook, als je het gaat gebruiken dan is het zeker handig, anders hoeft het niet zo nodig