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?



  • 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 😕



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



  • 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 😉


Log in to reply