[Gelöst] übergabe von std::wstring an dll schlägt fehl

[donelik]

guten tag liebe mit-zfxler,

ich habe da mal ein kleines riesenproblem.

ich habe ein interface welches in einer dll bedient wird. diesem interface übergebe ich 2 std::wstring
objekte. sobald ich das programm dann ausführe, läuft es bis zur besagten übergabe, aber sobald die
funktion in der dll fertig ist, fliegt mir mein programm um die ohren.

code im programm (exe):

Code: Alles auswählen

Urks::Plugin::Guier::CObject* pDebugWindow = this->getGuierInterface()->createObject(L"Window", L"DebugWindow");

code in der dll:

Code: Alles auswählen

Urks::Plugin::Guier::CObject* UrksGuier::CGui::createObject(std::wstring strFactoryName, std::wstring strObjectName) {
	/* den code hier drin habe ich ausgelassen, da das programm auch bei dieser leeren funktion abstürzt */
	return 0;
}

debug-ausgabe:

HEAP[UrksCore.exe]: Invalid Address specified to RtlValidateHeap( 00370000, 003432A8 )
Windows hat einen Haltepunkt in UrksCore.exe ausgelöst.
Dies kann auf eine Beschädigung des Heaps zurückzuführen sein, die auf ein Problem in UrksCore.exe oder in einer der geladenen DLLs hinweist.

callstack und haltepunkt:


meine meinung:
sieht für mich so aus, als würde der destruktor der std::wstring das problem verursachen. sobald ich die variablen als
referenz übergebe funktioniert alles wie soll. was noch recht interessant ist: der fliegt erst ab einer stringgröße von
> 7 zeichen weg ...

weitere informationen:
die dll hat nur einen einstiegspunkt

Code: Alles auswählen

extern "C" {
	__declspec(dllexport) Urks::Plugin::CInterface* factory(Urks::Core::CInterface& CoreInterface) {
		static UrksGuier::CGui theone(CoreInterface);
		return &theone;
	}
}

die klasse CGui implementiert bloss die schnittstelle die in der exe gebraucht wird.

für hinweise, vorschläge oder gar die lösung bin ich sehr dankbar
euer stiller mitleser

<p.s.> ich glüße lechhelzlich meinen mentol </p.s.>

[Aramis]

ich habe ein interface welches in einer dll bedient wird. diesem interface übergebe ich 2 std::wstring
objekte. sobald ich das programm dann ausführe, läuft es bis zur besagten übergabe, aber sobald die
funktion in der dll fertig ist, fliegt mir mein programm um die ohren.

Vorsicht bei DLLs. Sie haben jeweils einen separaten Heap, d.h. alles, was von DLL A alloziert wird muss auch von DLL A wieder freigegeben werden. Außer du benutzt eine zentrale Heapverwaltung, wie es beispielsweise der Fall ist wenn *alle* Module gegen die DLL-Version der Laufzeitbibliotheken gelinkt sind (/Md). Dann verwenden alle Module die gleichen, aus der CRT-DLL importierten Heaproutinen. Aller Speicher wird somit von der CRT-DLL aus angefordert und auch wieder gelöscht.

Ebenso könnten nicht-binärkompatible STL-Versionen schuld sein. Alle Module sollten mit den selben Settings für _SECURE_STL und _ITERATOR_DEBUGGING kompiliert werden, ansonsten gibt es ganz gerne mal kleine oder auch größere Probleme :-)

Alex

[donelik]

verdammt schnelle antwort. vielen dank dafür.

ich habe die 2 define gesetzt was aber auch keine ergebnisse brachte. die laufzeitbiliothek ist bei allen modulen "Multithreaded-Debug (/MTd)".
aber wenn ich die std::wstrings übergebe, werden die ja kopiert (copy-konstruktor) und sollten dann ganz normal wieder freigegeben werden.

[Aramis]

ich habe die 2 define gesetzt was aber auch keine ergebnisse brachte. die laufzeitbiliothek ist bei allen modulen "Multithreaded-Debug (/MTd)".

Setz die Laufzeitbibliothek auf Multithreaded-(Debug)-DLL und deine Probleme werden verschwinden :-)

Btw: Die Defines müssten

Code: Alles auswählen

#define _SECURE_SCL=0
#define _HAS_ITERATOR_DEBUGGING=0

lauten und global in den Projektsettings oder per Eigenschaftenblatt gesetzt werden. Dann entfallen alle Debugfeatures der STL-Implementierung und Iteratoren o.ä. werden nahezu so schnell wie direkte Pointerarithmetik. Sehr zu empfehlen falls du mal mit Performanceproblemen in der STL kämpfen solltest.

aber wenn ich die std::wstrings übergebe, werden die ja kopiert (copy-konstruktor) und sollten dann ganz normal wieder freigegeben werden.

Genau, aber das Erstellen macht der Aufrufer, also Modul A. Für's Löschen ist aber der Aufgerufene, Modul B, verantwortlich. Daher geht es auch mit Referenzen weil das Objekt dann im Besitz von Modul A verbleibt :-)

was noch recht interessant ist: der fliegt erst ab einer stringgröße von
> 7 zeichen weg ...

Auch das passt in's Bild. Die std::(w)string-Implementierung der Microsoft-STL verwendet für kleine Strings einen statischen Buffer der Größe 16 Byte. 7 UTF-16-Zeichen + Terminator = 16 Bytes. Erst bei längeren Strings wird also tatsächlich der Heap angezapft.

Alex

[donelik]

ich muss sagen: danke :)

alle probleme sind gelöst, gut zu wissen das es "nur" ein config problem war, und mein code sauber ist hehe

[donelik]

nochmal ein nachhaker....

wenn ich die dll runtimes nutze, setzt das aber vorraus das alle die mein programm nutzen wollen (bzw. sollen :) ) die dll haben. ein dll walker hat mir geflüstert es wäre die "MSVCP80D.DLL" (dürfte die debug version sein ... ).

ich kann jetzt leider nicht prüfen oder die release version überall verfügbar ist, aber die debugversion der runtime dll ist nicht bei mir auf arbeit...

ich schätze mal dieses problem ist nicht umgehbar, deshalb gibt es auch irgendwo in den tiefen des internets das entsprechende package was ich meine software beilegen muss ... bloss wo ?

[dowhilefor]

Erstmal, debug versionen solltest du eh nicht verteilen ;) womit auch die Anbindung an die ***d.dlls wegfällt, und das was du suchst, müsste eigentlich in den Visual Studio C++ Runtime Components enthalten sein.
Link

[donelik]

jop versteht sich von selbst.

vielen dank, der link war fast richtig. ich habe die 2005er version :).

kann es sein das die debug dlls dort nicht mitgliefert werden? kann leider erst morgen die release version meines programms hier testen.

vg
eric

[Aramis]

Die Debug-DLLs liegen in einem Unterverzeichnis der VC-Installation (.\vc\redist\Debug_NonRedist\x86\Microsoft.VC80.DebugCRT\). Sie sind aber, wie von Nico bereits erwähnt, nicht zur Weitergabe an den Endnutzer gedacht und ergo auch nicht im Installer enthalten.

Im Prinzip kannst du übrigens auch die benötigten Release-DLLs (.\vc\redist\x86\Microsoft.VC80.CRT\) in's Verzeichnis deines Programms kopieren und direkt mit ihm weitergeben. Das ist vielleicht nicht unbedingt die von Microsoft gewollte Variante, aber es ist die Beste ;-)

Alex

[bueyuekt]

Also du könntest das ganze mit dem Konfigurieren vermeiden, wenn du statt

Code: Alles auswählen

Urks::Plugin::Guier::CObject* UrksGuier::CGui::createObject(std::wstring strFactoryName, std::wstring strObjectName)

deine Methode so deklarierst:

Code: Alles auswählen

Urks::Plugin::Guier::CObject* UrksGuier::CGui::createObject(const wchar_t* strFactoryName, const wchar_t* strObjectName)

Du kannst dann in der Methode deine wstring objekte initialisieren....

Bei solchen Parameterübergaben würde ich übrigends in jedemfall die Standarddatentypen immer bevorzugen.

Nur mal so...

[Aramis]

Volle Zustimmung, gerade wenn mehrere Compiler im Spiel sind ist das mit Abstand die beste Möglichkeit. Man kann sie sogar noch etwas kaschieren bzw. rückwärtskompatibel einsetzen indem man die std::wstring-Methoden doch anbietet, aber als inline deklariert und auf die wchar_t*-Methoden umleitet. Damit sind Probleme ebenfalls ausgeschlossen.

[donelik]

Sehr interessant. Werde ich glatt mal austesten heute Abend. Hätte nicht gedacht das nach meinem "Danke-Post" hier noch was los ist :)