DLL - Heapproblem - Methodenaufruf

hustbaer

Ich hoffe die DLL, die LIB und das Programm compilierst du mit dem selben Compiler und den selben Einstellungen... ja? Wenn nicht wundert es mich nicht dass da irgendwo was crasht.

Files in Projekten zu duplizieren ist auch keine gute Idee, normal macht man ein "include" Verzeichnis, da drunter ein "MeineDll" Verzeichnis (den Namen der DLL halt), und da legt man seine public Header Files rein. Dann setzt du auf das "include" Verzeichnis einen include Pfad, und kannst die Datei mit "#include <MeineDll/blubb.h>" includieren. Das .cpp File gehört nur in die DLL, dann musst du bloss die entsprechende Klasse aus der DLL exportieren (mit "__declspec(dllexport)" für Compiler die diese Extension kennen), und schon brauchst du das .cpp File nur 1x in der DLL und sonst nirgends mehr. Damit bist du dann die lästigen und gefährlichen Kopien los (gefährlichen weil es nicht grad gut ist wenn man eines dieser Files ändert und dann vergisst es neu über die Kopien drüberzukopieren).

Pellaeon

Also erstma ja ich nutze VS 2005, die Standard-Edition
glflags.exe hab ich nicht gefunden bei mir, muss ích mal im Netz suchen

@hustbaer: was für Einstellungen müssen denn alles gleich sein? Ich habe jetzt die cpp in die statische Lib ausgelagter und in der DLL diese mit dazugelinkt.
Das eigentliche Programm verwendet auch diesselbe Lib. Da es da keine Compileprobleme gibt, dachte ich dass die EInstellungen soweit hinhauen, da ansonsten ja meist der Linker spuckt.
Laufzeitbibiliothel ist diesselbe(momentan Multithreaded-DLL in der DLL und der lib), beides ohne Optimierung mit Debuginfogenerierung

Jochen Kalmbach

Pellaeon schrieb:

Also erstma ja ich nutze VS 2005, die Standard-Edition
glflags.exe hab ich nicht gefunden bei mir, muss ích mal im Netz suchen

Natürlich hast Du es nicht gefunden; hab ich doch geschrieben...
http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx

Pellaeon

@jochen: du meinst sicher gflags.exe ohne das erste l?
Auf meiner in WinXP-CD, welche schon SP2 hat,wars mal wieder net drauf *hmpf*, habs aber auf ner SP2-Update CD gefunden und installiert.

Wie gehts nun weiter?
Hab die exe gestartet aber ein "Full Page Heap" in den Optionen nicht gefunden, allerdings diverse andere "enable heap ..."
und wie muss ich dass dan korrekt starten?
Ich habe oben das "image file options" gewählt, bei "Command line" den Pfad der exe angegeben und gestartet, der bleibt dann aber einfach stehen irgendwie.
Was muss ich da noch machen?

Danke für die Hilfe

edit: ok habe mal von deinem Link gezogen, da ist die gflags aktueller und ich habe die von dir beschriebenen Registerkarten

Jochen Kalmbach

Du musst es "Page Heap" im "Image"-Tab aktivieren und oben Deine EXE auswählen. Dann auf "Start" drücken... wenn jetzt ein Fehler passiert sollte er im debugger laden...

Pellaeon

Hm ich habe mal ein bisschen rumprobiert, aber nicht so wirklich was raugefunden damit.
Kompilieren tue ich alles(dll, lib und exe) mit Multithreaded-debug, das ist also überall gleich.
Das Problem scheint aufzutreten bei der Call by value-Übergabe von 2 wstring-Objekten(Typ aus der STL).
Ich habe mal testweise ein in der DLL erstelltes Objekt in der exe mit delete freigegeben. Das hat keinen Fehler erzeugt, ging also erstmal. Genutzt habe ich new und delete. Der STL-Standardallokator benutzt doch aber auch nur operator new und operator delete.
In der MSDN habe ich bisher auch nur den Hinweis gefunden, dass es crasht, wenn man 2 verschiedene C-Runtimes nutzt, was ich ja nicht mache.(http://msdn2.microsoft.com/en-us/library/ms235460(VS.80).aspx)

So ich werde erstmal aus den call by value Referenzen machen(konnt ich nur noch nicht testen, weil dadurch jetzt erstmal ein paar Linkerfehler auftreten, dass wstring-Kosntruktor in der lib schon definiert ist oO). Aber in einer anderen DLL hat es so erstmal gefunzt.

Trotzdem würde es mich mal interessieren, warum das vorherige nicht geht.

Jochen Kalmbach

Wenn Du sowas machst (STL/CRT Dinge zwischen EXE und DLL austauscht), dann *musst* Du die DLL-Version der CRT verwenden!

Pellaeon

ahso,

danke für deine Hilfe!

hustbaer

@Pellaeon:

Ist jetzt eh egal (weil Problem gelöst), aber ich meinte auch die Runtime Version, ggf. noch weitere Dinge wie Unicode vs. nicht Unicode etc.

CodeFinder

hustbaer schrieb:

@Pellaeon:

[...] vs. nicht Unicode etc.

ANSI .

Pellaeon

hustbaer schrieb:

@Pellaeon:

Ist jetzt eh egal (weil Problem gelöst), aber ich meinte auch die Runtime Version, ggf. noch weitere Dinge wie Unicode vs. nicht Unicode etc.

Das hat überein gestimmt. Liegt wohl wirklich daran, dass exe und dll 2 "crt-Manager"(mir fällt grad kein besserer Ausdruck ein^^) haben durch das statische linken.
Das einzige was mich wundert: dass das delete außerhalb auf ein Objekt meienr eigenen Klassen erstmal keinen Fehler ausgelöszt hat. new und delete basieren dann irgendwo ja auch auf der crt(wird ja meistens intern auf malloc und free zurück geführt)
Naja bei Gelegenheit muss ich mal die MSDN nach dem crt zeugs durchforsten und mich da etwas mehr einlesen als bisher.

hustbaer

@CodeFinder: naja, sagen wir einfach narrow vs. wide

@Pellaeon: es liegt daran dass die Runtime-Lib den Heap verwaltet, und wenn du die Runtime-Lib statisch zur DLL und EXE dazulinkst (so dass du dann 2 Kopien davon hast), dann haben DLL und EXE auch 2 verschiedene Heaps. Den Punkt hatte ich vergessen. Wenn du dann in der DLL was anforderst und es in der EXE freigibst (oder umgekehrt), dann schnalzts halt.

Wenn du z.B. eine Klasse Foo in der DLL implementiert hast, in der EXE dann "new Foo" und "delete foo" machst, dann geht das - operator new und operator delete sind dann beide die Version aus der EXE, gleicher Heap, also gehts. Wenn du aber z.B. einen std::string von einer Funktion aus deiner DLL zurückgibst, dann wird der Speicher den std::string intern anfordert in den DLL angefordert, aber in der EXE freigegeben. Und das geht dann nichtmehr.

Grundsätzlich sollte man wenn man C++ DLLs unter Windows verwendet immer in allen DLLs und EXEs die "Multithreaded DLL Runtime" verwenden (bzw. "Multithreaded Debug DLL Runtime" für Debug Builds - du darfst dann aber auch nicht eine Release DLL mit einer Debug EXE oder so mischen). Es sei denn man weiss ganz ganz genau was man tut - bloss da gibts auch wenige Fälle wo es wirklich Sinn macht unterschiedliche Runtimes zu mischen.

Vonwegen Release und Debug nicht mischen hilft es im Übrigen sehr wenn man die Debug Version einfach anders nennt, z.B. "Foo.dll" (Release) und "Foo-d.dll" (Debug) oder so. Dann kann man auch die DLL und LIB Files im gleichen Verzeichnis liegen haben...