Absturz bei std::wifstream und read()



  • Hallo,

    ich hab Daten in eine Datei geschrieben und möchte die Daten dort wieder auslesen. Jedoch stürtzt die Anwendung beim zweiten read() ab. Es werden Strukturen in die Datei geschrieben, 2 Strukturen + weitere je einen pro Datensatz.

    Das Einlesen der ersten Struktur ist soweit ok, aber beim versuch die zweite Struktur einzulesen stürtzt die Anwendung ab. Die Fehlermeldung lautet etwa ...

    "Unbehandelte Ausnahme bei 0x000000 Meine.exe : 0xC0000005 Zugriffsverletzung beim Lesen an Position 0x0000000"

    Dann wird eine stelle in der streambuf markiert mit der zeile "else if (_Traits::eq_int_type(_Traits::eof(), _Meta = uflow()))"

    Wenn ich nach dem ersten block mit good() prüfe liefert sie TRUE zurück, wenn ich mit tellg() mir die Position des lesepointers hole gibt er 0 zurück und bleibt 0 auch wenn ich mit seekg diesen setzten möchte. Beim setzten habe ich die größe der ersten Struktur probiert. eof() liefert kein TRUE zurück.

    So schreibe ich die Daten

    wofstream pFileStream;
    IMBUE_NULL_CODECVT(pFileStream) ;
    pFileStream.open(sTargetFilepath.c_str(), ios::out | ios::binary | ios::trunc); 
    
    struct LANGFILEHEADER_STRUCT		pHeaderblock;
    struct LANGFILEINFORMATION_STRUCT	pInfoblock;
    struct LANGFILESTRINGDATA_STRUCT	pDatablock;
    
    // Quelltext zum befüllen der Struktur rausgeschnitten
    
    pFileStream.write(reinterpret_cast<wchar_t*>(&pHeaderblock), sizeof(pHeaderblock)); 
    
    // Quelltext zum befüllen der Struktur rausgeschnitten
    
    pFileStream.write(reinterpret_cast<wchar_t*>(&pInfoblock), sizeof(pInfoblock));
    

    So lese ich die Daten ... bzw versuche es

    wifstream pFileStream;
    IMBUE_NULL_CODECVT(pFileStream) ;
    pFileStream.open(pDateiDialog.GetPathName().GetBuffer(), ios::in | ios::binary); 
    
    struct LANGFILEHEADER_STRUCT pHeaderblock;
    struct LANGFILEINFORMATION_STRUCT pInfoblock;
    struct LANGFILESTRINGDATA_STRUCT pDatablock;
    
    pFileStream.read(reinterpret_cast<wchar_t*>(&pHeaderblock), sizeof(pHeaderblock)); 
    
    /*
    Bei dem folgenden read() stürtzt die Anwendung ab. Wie gesagt liefert vor 
    dem Aufruf good() ein TRUE zurück, EOF() ein FALSE und tellg() 0 (aber nicht -1)
    und seekg() scheint den  Wert von tellg() nicht zu beeinflussen
    */
    pFileStream.read(reinterpret_cast<wchar_t*>(&pInfoblock), sizeof(pInfoblock));
    

    Die erste Struktur wird ohne Probleme eingelesen, die Daten sind dann auch vorhanden. Ohne den zweiten read() Auruf stürtzt die Anwendung nicht ab.



  • In einem Forum habe ich ein posting gefunden das von einem Bug bei tellg() berichtet, das der erste aufruf immer 0 zurückliefert. Wenn ich direkt nach den öffnen tellg() aufrufe, und dann nach dem ersten read() nochmal, dann wird mir '34' zurückgeliefert.

    pHeaderblock ist 16 Bytes groß und zusammen mit dem "Byte Order Mark" macht das 17 * 2 da Unicode als Position '34'. Und die strukturen sind bei beiden Identisch (beim lesen und schreiben) und gleichgroß. Ich hab dann noch ein bissle mit seekg() rumgespielt aber dann bekomme ich meldungen mit stack around variable bla is corrupt.



  • Hallo,

    warum verwendest du überhaupt einen wifstream/wofstream, wenn du binär aus der Datei liest/schreibst? Nutze einfach einen ifstream/ofstream, und dann sollte es besser aussehen.

    MfG,

    Probe-Nutzer



  • Also ich hab jetzt nochmal rumprobiert, letztendlich liegt es scheinbar nur an der zweiten Struktur. Senn ich diese mit seekg() einfach überspringe und die Strukturen der Datensätze einlesen funktioniert es. ich weiss nicht wieso aber bei der zweiten Struktur hat der seine probleme, es sind vier wchar_t Variablen drin. bei den anderen nur 4 x integer und bei den Datensätzen ein integer und eine wchar_t Variable.

    warum verwendest du überhaupt einen wifstream/wofstream, wenn du binär aus der Datei liest/schreibst? Nutze einfach einen ifstream/ofstream, und dann sollte es besser aussehen.

    Weil ich mir denke das ich nur so die Daten Unicode in die Datei bekomme. Würde ich ifstream/ofstream nehmen müsste ich selbst alles so umwandeln das ich das später wieder als unicode in die variablen bekomme.



  • münsterländer schrieb:

    Weil ich mir denke das ich nur so die Daten Unicode in die Datei bekomme. Würde ich ifstream/ofstream nehmen müsste ich selbst alles so umwandeln das ich das später wieder als unicode in die variablen bekomme.

    Äh, Du schreibst die Daten doch binär. In dieser Betrachtung gibt es nichtmal irgendwelche Zeichen, die Unicode sein könnten.



  • ok, ihr habt wohl recht. habs gerade umgestellt und jetzt scheints keine probleme mehr zugeben. hatte die befürchtung das sonderzeichen und schriftzeichen wie die japanischen usw nicht gespeichert werden wie es sollte. aber es funktioniert jetzt.

    ich habe vor dem umstellen auf ifstream/ofstream schon wieder frust geschoben weil es in der Debug Version funktionierte aber in der Release nicht, dort isser wieder abgestürtzt.


Anmelden zum Antworten