Crash durch code, der nicht verwendet wird

Hi,

ich habe hier einen seltsamen Effekt, für den ich keinerlei Erklärung habe - deswegen wäre jeder auch noch so absurde Hinweis oder Tipp willkommen!

Ich habe ein Programm, welches gegen zwei Bibliotheken liba.dll und libb.dll linkt. Wenn ich nur einen Aufruf

liba_init()

drin habe, dann funktioniert alles. Ich vermute mal, in diesem Fall wird gar nicht erst gegen die nicht benutze libb.dll gelinkt. Nehme ich jetzt einen Aufruf an die libb.dll hinzu:

liba_init()
libb_init()

...dann stürzt mir mein Programm an einer ganz anderen Stelle ab - allerding schon im Aufruf von liba_init()! Um das klar zu stellen: liba_init() schmiert ab, wenn libb_init() im Programm vorkommt, aber ohne dass libb_init() zu diesem Zeitpunkt überhaupt schon mal aufgerufen wurde (und dabei hätte Schaden anrichten können).

Das einzige, was mir momentan auffällt, ist die Tatsache, dass libb_init() variable Parameterlisten verwendet:

__declspec(dllexport) unsigned long __cdecl libb_init_if(int *var,...)

Die libb.dll wird bereits mit __cdel-Konvention gebaut (auch in den Codesettings des VS). Und: das Problem tritt nur unter Windows auf, unter Linux läuft der gleiche Code komplett problemlos.

Hat jemand einen Tipp oder eine Idee, was das sein könnte?

Danke!

- Programm/Libs nicht mit dem gleichen Compiler und den gleichen Flags übersetzt
- Symbole mit gleichem Namen in den Dlls

manni66 schrieb:

- Programm/Libs nicht mit dem gleichen Compiler und den gleichen Flags übersetzt

Würde das nicht erst beim Aufruf der libb-Funktionen zu Problemen führen?

manni66 schrieb:

- Symbole mit gleichem Namen in den Dlls

Die Namen passen, in so einem Fall sollte aber auch der Linker warnen bzw. einen Fehler ausgeben?

hustbaer

Könnte sein dass die DllMain Funktion der Library B das Problem verursacht. Die wird nämlich ausgeführt sobald die DLL geladen wird, nicht erst wenn man wirklich ne Funktion aufruft.
Überprüf mal ob die Library B ohne den init Aufruf noch referenziert wird (=> Dependency Walker).

Sonst kannst du noch probieren das Linken mit der DLL zu erzwingen ohne dass du die Init-Funktion dann wirklich aufrufst.
Einfache Möglichkeit:

if (GetTickCount() == 0) // Wird so-gut-wie nie erfüllt sein
    libb_init();

Wenn das so dann nicht crasht, dann würde ich mal z.B. per Debug-Ausgaben sicherstellen dass der Crash nicht ganz woanders passiert als vermutet (gibt Situationen wo der Callstack im Debugger nicht stimmt, auch wenn das recht selten ist).

So, ich habe noch ein paar Infos:

weder liba.dll noch libb.dll verwenden eine DLLMain, daher kann es also nicht kommen. Beide DLLs verwenden intern aber wxWidgets, allerdings mit einem großen Unterschied:

- liba.dll verwendet nur ganz wenige Funktionen von wxWidgets
- libb.dll ist eine ausgewachsene Software, welche wxWidgets intensiv benutzt

Meine Idee jetzt: eventuell wird da irgendwo ein statisches wxWidgets-Objekt erzeugt, bevor liba.dll oder libb.dll wxwidgets ordnungsgemäß initialisieren könnten. Gefunden jabe ich aber noch keinne Schuldigen dafür

SG1

Ohne wxwidgets jetzt zu kennen - ist es eventuell ein Problem, wenn wxwidgets 2x initialisiert wird?

hustbaer

Zonggg schrieb:

weder liba.dll noch libb.dll verwenden eine DLLMain

Och die haben ziemlich sicher ne DllMain , bloss halt keine "selbst geschriebene".

Weil: Jede DLL die statische Objekte hat welche dynamisch initialisiert werden müssen hat automatisch ne DllMain .
Und alles wo das nicht zutrifft hat trotzdem immer noch ne DllMain , bloss u.U. eine die recht wenig tut