std::ifstream#close() führt zu einem Fehler

Nathan

Mr.Long schrieb:

Ich rufe std::ifstream#close in einem anderen Modul als der Exe auf (einer DLL), da kommt der Fehler, wenn ich aber close in der Exe aufrufe, kommt der Fehler nicht.
Bzw. wie findet man so einen Fehler am besten?

Ist die DLL mit denselben Einstellungen und der selben ABI?
Ansonsten kann es leicht zu solchen Fehlern kommen.

JulianH

Was meinst du mit ABI? Ja das sind die selben Einstellungen, habe gerade nochmal alles überprüft.
Ich glaube langsam es liegt an der gelinkten Ruby-Dll.

TNA

Unter Windows ist es im allgemeinen nicht möglich, Objekte aus der C++-Standardbibliothek über Bibliotheksgrenzen hinweg zu nutzen, da diese gegen unterschiedliche Implementierungen der C++-Standardbibliothek gelinkt sein können.

In den Dlls sind die Standard-Libs auch gelinkt.

MichelRT

Mr.Loong schrieb:

In den Dlls sind die Standard-Libs auch gelinkt.

Genau das erzeugt ja das Problem wenn die Compilerversionen und die Einstellungen nicht gleich sind.

JulianH

Da ich echt am verzweifeln bin und ich hoffe, dass irgendwer Zeit hat sich mein Projekt mal anzusehen, habe ich jetzt einfach mal mein Projekt hochgeladen:
http://www.loaditup.de/files/831699_6g5rdf742n.rar
Ich benutze Visual Studio 2013 Ultimate, das DirectX SDK wird verwendet und die Ruby-Lib gelinkt (die DLL ist beim ersten Upload dabei):
http://www.loaditup.de/files/831701_fwzqa372pu.rar

Wenn ihr euch das Projekt runtergeladen habt, findet ihr 2 ofIStream.open und ofIStream.close()s, eines davon ist in der Main und das Andere in der Funktion ERDL::L::CRubyFileLoader::fn_LoadRubyFiles(szBaseName) welche in der main aufgerufen wird. Beim Aufruf in der Main klappt alels, beim Aufruf in der fn_LoadRubyFiles-Funktion kommt der besagte Fehler.

Wäre cool, wenn sich das mal wer ansehen könnte.

JulianH

MichelRT schrieb:

Mr.Loong schrieb:

In den Dlls sind die Standard-Libs auch gelinkt.

Genau das erzeugt ja das Problem wenn die Compilerversionen und die Einstellungen nicht gleich sind.

Könnten also auch die Einstellungen beim Kompilieren der msvcr120-ruby210.dll falsch gesetzt gewesen sein?

Mr.Long schrieb:

MichelRT schrieb:

Mr.Loong schrieb:

In den Dlls sind die Standard-Libs auch gelinkt.

Genau das erzeugt ja das Problem wenn die Compilerversionen und die Einstellungen nicht gleich sind.

Könnten also auch die Einstellungen beim Kompilieren der msvcr120-ruby210.dll falsch gesetzt gewesen sein?

Nicht falsch, sondern anders.

JulianH

Und was für Einstellungen können das sein? Kann man die Auflisten? Oder wie soll ich den Fehler jetzt beheben? Ruby neu kompilieren? Oder meine Einstellungen denen der DLL anpassen?
Ich habe damals den Ruby Interpreter halt so kompiliert wie es in der Readme stand:

nmake
nmake test
nmake install

JulianH

Beim Debugen mit Ollydbg habe ich herausgefunden, dass wenn ich ifstream im Modul, welches Ruby linkt, bei close() über das Modul msvcr120-ruby210.dll die fclose-Funktion von dem Modul msvcr120 (C:\Windows\SysWow64\msvcr120.dll). Bei close() Aufrufen aus dem anderem Modul (welches nicht Ruby Linkt) wird die fclose() funktion ohne umwege über andere DLLs direkt aufgerufen und dann zwar im Modul msvcr1_1 (C:\Windows\SysWow64\msvcr120d.dll). Könnte die in diesem Fall falsch geladene DLL der Fehler sein?

firefly

Mr.Long schrieb:

Beim Debugen mit Ollydbg habe ich herausgefunden, dass wenn ich ifstream im Modul, welches Ruby linkt, bei close() über das Modul msvcr120-ruby210.dll die fclose-Funktion von dem Modul msvcr120 (C:\Windows\SysWow64\msvcr120.dll). Bei close() Aufrufen aus dem anderem Modul (welches nicht Ruby Linkt) wird die fclose() funktion ohne umwege über andere DLLs direkt aufgerufen und dann zwar im Modul msvcr1_1 (C:\Windows\SysWow64\msvcr120d.dll). Könnte die in diesem Fall falsch geladene DLL der Fehler sein?

Ja du mischt hier debug runtime mit der relase version. (Beachte das d am ende des dll namen)

JulianH

Ich habe jetzt Ruby nochmal mit dem Zusatz -MDd kompiliert. Wenn ich nun mit Ollydbg durchsteppe springt er auch nicht mehr in die msvcr120, sondern eben in die msvcr120d, was ja jetzt soweit eigentlich ganz gut ist. Nur bekomme ich noch immer an der selben Position den selben Error.

EDIT: Nein, ich war nur zu dämlich zu checken, dass irgendwo meine Compileroption überschrieben wurde. Der Kompiler hat nämlich den Interpreter wieder mit /MD kompiliert... Jetzt wo ich das richtig mit /MDd kompiliert habe läuft's.