ich bekomme einen Fehler beim Verlassen einer DLL-Funktion:

HEAP[Test.exe]: Invalid Address specified to RtlValidateHeap( 02760000, 02B72A48 )

Auf dem Callstack befindet sich folgende Fkt.:

> msvcr80d.dll!_CrtIsValidHeapPointer(const void * pUserData=0x02b72a68) Line 1963 C++

Der Fehler tritt (auch hier) beim Verlassen der Fkt. auf. In der darunter liegenden Fkt. im Callstack habe ich folgende Beschreibung zu der Fkt. gefunden:

/*
         * If this ASSERT fails, a bad pointer has been passed in. It may be
         * totally bogus, or it may have been allocated from another heap.
         * The pointer MUST come from the 'local' heap.
         */
        _ASSERTE(_CrtIsValidHeapPointer(pUserData));

Da die Fkt. _CrtIsValidHeapPointer() beim Beenden fehlerhaft ist, weis ich grad nicht weiter. Der DLL-Aufruf funtioniert aus einem anderen ähnlichen Kontext problemlos.

Deswegen vermute ich, dass es möglichweise am Aufruf der DLL oder an den Projekteinstellungen liegen kann, aber ich hab keine Ahnung, wonach ich suchen muss.

Auf der anderen Seite könnte aber auch der DLL-Kode fehlerhaft sein, denn das Problem tritt ja beim Verlassen der DLL-Fkt. auf, also läuft vllt. das Aufräumen nicht ganz rund.

Habt ihr einen Tipp?

Gruß,
don_basto.

Der Code in der DLL ist eher nicht fehlerhaft. Moeglicherweise rufst du die DLL-Funktion mit falscher Calling-Konvention auf.

Vllt. doch, die DLL habe ich programmiert.

Die Calling-Konvention sollte stimmen. Hatte das Problem schon und hab jetzt vor jeder DLL-Fkt. im Header ein __cdecl sehen.

Es ist aber wahrscheinlicher, dass es am Aufruf liegt. Der Unterschied zw. dem korrekten und dem fehlerhaften Aufruf ist das Objekt, welches den Aufruf durchführt:
[Korrekt] statisches Objekt innerhalb einer Fkt.
[Fehler] Pointer, der Objekt mit new erzeugt

Kann's daran liegen?

zeig doch endlich mal etwas code...

Was willst denn sehen?

Da ich das Problem selbst nicht eingrenzen kann, weiss ich nicht, was relevant wäre.
Ich habe zB. eine Wrapper-Klasse, die alle Anfragen an die DLL kapselt?
Oder den DLL-Header?

<edit>
Komsicherweise tritt der Fehler nur bei einer Fkt. der DLL auf. Die anderen Fkt. arbeiten ohne Probleme. Bei dieser einen Fkt. tritt der Fehler beim Austritt auf.
</edit>

// dll header
MY_DLL	bool C_CALL	myLoad(const std::string filename);

Wenn ich den Callstack weiter runtergehe, treffe ich irgendwann auf den basic_string - Destruktor.

> msvcp80d.dll!std::basic_string<char,std::char_traits<char>,std::allocator<char> >::~basic_string<char,std::char_traits<char>,std::allocator<char> >() Line 878 C++

Innerhalb der DLL-Fkt. reiche ich den Anruf nur an eine Klasse weiter:

bool myLoad(const std::string filename)
{
	bool res = singleton().load(filename);

	// hier kommt jetzt der Fehler ..
	return res;
}

Diese Memberfkt. arbeitet jetzt mit einer Referenz:

bool	load(const std::string&  filename);

Hilft das weiter?

Bei den Projekteinstellungen hat sich die 'runtime library' unterschieden. Jetzt läuft's prima. Bei dem anderen korrekten Projekt war die Einstellung richtig.

Gruß,
don_basto.

<edit> btw: Bedeutet das, dass man aus VB, C#, etc. die DLL nicht benutzen kann? </edit>

Bedeutet das, dass man aus VB, C#, etc. die DLL nicht benutzen kann?

Wenn Du kein VB/C+ hast, hat es für Dich keine Bedeutung...
Aus VB.NET/C# kann man halt nur C-Funktionen aus DLLs aufrufen (oder COM).

// so steht's im Header
extern "C" __declspec(dllexport) bool __cdecl myLoad(std::string filename);

// richtiger C-Stil ???
extern "C" __declspec(dllexport) bool __cdecl myLoad(const char* filename);

Das einzigste, was nicht C ist, ist der namespace (std) und vermutlich der String-Typ.

Hätte ich die Aufrufprobleme nicht mit dem 2. Fkt.-deklaration gehabt?

Hätte ich die Aufrufprobleme nicht mit dem 2. Fkt.-deklaration gehabt?

fast 100%iger Treffer... (bool würde ich noch durch BOOL ersetzen und noch stdcall verwenden...)

fast 100%iger Treffer... (bool würde ich noch durch BOOL ersetzen und noch stdcall verwenden...)

Hehe. War geraten.

Hab von normalem C keine Ahnung. Hast du einen Link, wo die Regeln für eine saubere C-Schnittstelle zur DLL-Programmierung zu finden sind?

Das MSDN sagt, das C kein bool kennt, also muss es raus.
Aber __cdecl ist laut MSDN die Standardkovention für C und C++, warum sollte es durch __stdcall ersetzt werden?

Aber __cdecl ist laut MSDN die Standardkovention für C und C++, warum sollte es durch __stdcall ersetzt werden?

Ist nicht unbedingt notwendig... aber z.B. VB6 Applikationen können nur stdcall Funktionen aufrufen... und die gesamte WinAPI ist stdcall...

Ich habe unter Properties->Code Generation->Runtime Library von MT-Dll auf MT umgestellt, damit die DLLs auf anderen Rechnern starten. Nach der Umstellung, tun sie das auch, aber nun kommt wieder dieser Fehler.

Diesmal es stimmen die Aufrufkonventionen(__cdecl) und Runtime Library ist auch identisch.

Woran kann's noch liegen?

<edit>
Also ich hab ein Dll-Funktion folgendermaßen deklariert:

MY_DLL	void C_CALL myTest(const std::string test);

Wenn ich dies jetzt mit /MD kompiliere, kann ich es aufrufen und verwenden. Wenn ich es mit /MT kompiliere, ist bei der Zerstörung des Strings Schluss. Und zwar genau dann, wenn der String 16 oder mehr Zeichen besitzt.

Wenn ich auf den String verzichte, klappt's.

My_DLL	void C_CALL myTest(const char* test);

Was geht da in den Tiefen des Systems vor sich?
Warum erscheint der Fehler nur bei /MT?
Wieso sind Strings bis 15 Zeichen akzeptabel?

Ich hab keine Ahnung, ihr vielleicht?
</edit>

Wenn Du STL/MFC/ATL in Deiner DLL-Schnittstelle verwendest, dann musst Du die DLL-Version der CRT verwenden!!! Und alle Programme die diese DLL verwenden müssen mit den gleichen Compiler Settings für die CRT übersetzt werden (und natürlich den gleichen Compiler).

Und warum eigentlich?