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

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

  • J

    Hallo,
    sobald bei mir folgendes ausgeführt wird

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

    bekomme ich einen Laufzeitfehler, dass eine Zugriffsverletzung stattgefunden hat. Mein Callstack dazu sieht so aus:
    http://www.loaditup.de/files/831619_4gxys2vguz.png
    Die oben geschriebenen Zeilen stehen genauso in der fn_LoadRubyFiles-Funktion. Also stellen sich für mich 2 Fragen: 1. Wieso wird zwischendrin noch eine Funktion aus der msvcr120-ruby.dll (ein Visual Studio Kompilat des 2.0.1 Ruby Interpreters) aufgerufen? Und 2. Wieso bekomme ich einen Laufzeitfehler?
    Kann mir wer sagen, wie diese Adresse dorthin kommt?
    Werden da Adressen beim Linken der Ruby-Lib irgendwie vom Linker auf die msvcr120-ruby.dll ersetzt? Oder was passiert da im Hintergrund?

    Noch ein Bild vom Error und an welcher Stelle er auftaucht:
    http://www.loaditup.de/files/831623_34xcukeq9g.png

    EDIT:
    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.

    0
  • N

    Vermutlich ist szFilename kaputt.

    0
  • J

    Kann nicht sein, das Auslesen funktioniert nämlich.

    0
  • N

    Mr.Long schrieb:

    Kann nicht sein, das Auslesen funktioniert nämlich.

    Welches Auslesen? Und das muss nichts heißen.

    0
  • J

    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.

    0
  • S

    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();
    0
  • Mod 

    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 .

    0
  • J

    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.

    0
  • N

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

    0
  • J

    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?

    0
  • S

    Vielleicht kannst du da rein debuggen...

    0
  • N

    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.

    0
  • J

    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.

    0
  • T

    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.

    0
  • ?

    In den Dlls sind die Standard-Libs auch gelinkt.

    0
  • M

    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.

    0
  • J

    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.

    0
  • J

    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?

    0
  • ?

    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.

    0
  • J

    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
    0
Anmelden zum Antworten