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

JulianH

Kann nicht sein, das Auslesen funktioniert nämlich.

Nathan

Mr.Long schrieb:

Kann nicht sein, das Auslesen funktioniert nämlich.

Welches Auslesen? Und das muss nichts heißen.

JulianH

Ich hab's jetzt so drin stehen:

std::ifstream oFstream;
oFstream.open(szFilename, std::ifstream::in);
std::getline(oFstream, strBuffer);
oFstream.close();

läuft bis zu oFstream.close().
Ich habe auch noch herausgefunden, dass oFstream.close() im Releasemode ganz normal funktioniert.

Skym0sh0

Erstmal ist std::ifstream und std::ifstream::in im open doppelt gemoppelt. Zweitens gehört sowas in den Konstruktor und nicht erst als Methode danach dahin. Das gleiche gilt für close und den Destruktor.

Dann zeig mal ein Minimalbeispiel, das den Fehler reproduziert.
Denn das hier geht:

std::string szFilename = "myFile.txt";
std::ifstream ifs(szFilename);

std::string tmp;
ifs >> tmp;

ifs.close();

Columbo

std::getline(oFstream, strBuffer);

Falls beim Auslesen ein Fehler entsteht werden lediglich die State-Bits im Stream ( eofbit , failbit , badbit ) gesetzt. Es wird keine Exception geworfen oder das Programm terminiert. Prüfe doch mal mittels is_open .

JulianH

ich hatte auch schon if (oFstream.is_open()) vor oFstream.close() stehen, doch oFstream.open() gab true zurück.

EDIT: ich habe hier den Kompletten Code, welcher bei mir zu diesem Fehler führt, gepostet.

Nathan

Das heißt nichts, das ist ein Segfault.
Der Fehler kann in der ersten Zeile der Main liegen.

JulianH

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?

Skym0sh0

Vielleicht kannst du da rein debuggen...

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)