Hi, Am Samstag, 2. Februar 2008 19:27 schrieb Micha Lenk: > Bei mir führt das Ausführen von ktoblzcheck mit gültiger BLZ und > Kontonummer zu einem Segfault, wenn ktoblzcheck aus Version 1.11 oder > Version 1.14 gebaut ist, die shared library aber aus Version 1.16 gebaut > ist.
komisch, komisch. Leider weiß ich hier auch nicht weiter. Ich würde schon ein libktoblzcheck mit debug-Info brauchen, damit im backtrace wenigstens eine Zeilennummer vom Aufruf AccountNumberCheck::AccountNumberCheck () steht - ohne weitere Angaben kann ich nicht sagen, ob das eventuell ein Programmfehler sein könnte oder tatsächlich ein linking-Problem. > (gdb) backtrace > #0 0xb7e4b31f in std::basic_string<char, std::char_traits<char>, > std::allocator<char> >::basic_string () from /usr/lib/libstdc++.so.6 > #1 0xb7eac6dc in AccountNumberCheck::AccountNumberCheck () from > /usr/lib/libktoblzcheck.so.1 > #2 0x0804b7eb in main (argc=Cannot access memory at address 0x47a4b368 > ) at ktoblzcheck.cc:166 > Wenn ktoblzcheck und shared library aus der selben Version (1.16) gebaut > sind, kommt kein Segfault. > > Wenn ich das Konzept mit den SONAMEs richtig verstanden habe, dürfte es > ja eigentlich nicht zu diesem Segfault kommen, wenn ldd alle dynamischen > Bibliotheken findet. Kann es sein, dass bei der Bibliothek mal der > SONAME erhöht werden müsste? Bezüglich SONAME hab ich mich an die libtool-Doku-Vorschläge gehalten. Dementsprechend bleibt der major SONAME unverändert, solange keine der existierenden Funktionsaufrufe rausgenommen oder verändert worden sind. Nu ist mir nicht vollständig klar, wie sich Änderungen von C++-Klassen hier auswirken, aber da alle Konstruktoren/Destruktoren normale Funktionen sind (d.h. nicht-inline), hab ich das IMHO hier auch erfüllt. Also laut meinem Verständnis von SONAME ist das mit der Nummer 1 noch okay und von dort hätte kein segfault kommen dürfen. Aber zum weiteren Überprüfen müsste man vom backtrace oben genauer wissen, an welcher Stelle im Konstruktor der Aufruf des std::string-Konstruktors kommt, der zum crash führt. Gruß Christian ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Aqbanking-devel mailing list Aqbanking-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/aqbanking-devel
