Speicherproblem, was nicht beim Debuggen auftritt...



  • Hallo zusammen!

    Meine Anwendung läuft auf einen ZwAllocateVirtualMemory Error, sobald ich sie nicht über die VS2008 IDE debugge. Beim starten über die IDE läuft alles perfekt, der Fehler tritt nur dann auf, wenn ich die Exe manuell vom Explorer aus starte.

    Nutzt der Debugger vielleicht eine andere Methode des Speichermanagements? Wenn ja, wie gebe ich meiner Anwendung mit, dass sie automatisch diese Methode verwenden soll?

    Vielen Dank im Voraus,
    veryxRV

    EDIT:

    Sieht jemand in diesem Code ein Problem mit der Speicherverwaltung?

    LPSTR CONVJOB::GetPath()
    {
    	FILEHANDLER fHandler;
    	std::string strTemp = this->szFile;
    	char * cFilename;
    
    	strTemp = fHandler.CutFileToPath(strTemp);
    
    	cFilename = new char[strlen(strTemp.c_str())];
    	sprintf(cFilename, "%s", strTemp.c_str());
    
    	return cFilename;
    }
    


  • Ich kenne mich da auch nicht so gut aus, aber der Debugger initialisiert den Speicher irgendwie, so dass es passieren kann, dass ein Programm als Debug kompiliert (scheinbar) einwandfrei läuft und als Release eben nicht.

    Greifst du vielleicht auf nicht initialisierten Speicher zu o.ä.?



  • Ich habe leider keine Ahnung, da ich mich auf dem Gebiet wirklich kaum auskenne. Der VS Debugger gibt mir folgendes aus, wenn ich den Prozess manuell starte und dann dem Debugger zuweise:

    Unhandled exception at 0x77242613 in conv.exe: 0xC0000005: Access violation reading location 0x0205066a.



  • Ich würde nach dem Ausschlussprinzip alles nach und nach rausschmeissen, bis du ein laufendes Programm hast (und somit den Fehler gefunden hast). Halte Ausschau nach überschrittenen Feldgrenzen o.ä.

    Könntest du dir nicht auch die Adresse, an der der Fehler passiert ist (0x77242613), im Disassembly ansehen und so in etwa die Stelle lokalisieren, an der es kracht?



  • Ich bin schon nach dem Ausschlussprinzip vorgegangen und habe versucht, den Bereich einzugrenzen, musste dabei aber leider feststellen, dass der Fehler an beliebigen Stellen auftritt - und das beim selben Build...



  • 77242613 324e02          xor     cl,byte ptr [esi+2]        ds:0023:028d57fa=??
    

    Das ist die Stelle im Disassembly, kann damit nur leider nichts anfangen...



  • jetzt muss du nur noch den call-stack anschauen.
    (an der stelle 0x7... ist im normalfall irgendeine WindowsAPI funktion, die wahrscheinlich falsche parameter bekommt).



  • Im CallStack steht:

    conv!malloc+0x79
    conv!operator new+0x1f
    conv!std::_Allocate<char>+0x13
    conv!std::basic_string<char,std::char_traits<char>,std::allocator<char> >::_Copy+0x75
    conv!std::basic_string<char,std::char_traits<char>,std::allocator<char> >::assign+0x74
    conv!MENCODER::Compress+0x247
    conv!ConverterThread+0x1c0
    

    Ich kann dort noch diverse dinge ein/ausblenden, kann aber mit den Ausgaben nichts anfangen. Was zeigt mir denn der CallStack?



  • Das sagt dir aus, dass in der Funktion MENCODER::compress jemand versucht einem std::string irgendetwas zuzuweisen/kopieren, aber das speicher anlegen fehlschlägt, weil wahrscheinlich der heap irgendwoanders demoliert wurde.
    (vielleicht hat jemand über arraygrenzen geschreiben oder irgend ein reinterpret_cast oder sonstetwas).

    Nun solltest du alle stellen im program überprüfen, wo speicher angefordert/genutzt wird ob eben soetwas passiert.



  • Alles klar, danke. Ich melde mich zurück, wenn ich nichts finde, bzw. den Fehler gefunden habe 🙂



  • Das Programm besteht aus zwei Threads, kann es vielleicht sein, dass die sich in die Quere kommen, was die Speicherverwaltung angeht?

    EDIT:

    Sieht jemand in diesem Code ein Problem mit der Speicherverwaltung?

    LPSTR CONVJOB::GetPath()
    {
    	FILEHANDLER fHandler;
    	std::string strTemp = this->szFile;
    	char * cFilename;
    
    	strTemp = fHandler.CutFileToPath(strTemp);
    
    	cFilename = new char[strlen(strTemp.c_str())];
    	sprintf(cFilename, "%s", strTemp.c_str());
    
    	return cFilename;
    }
    


  • strlen() liefert die Länge eines Char-Arrays OHNE die '\0' Terminierung.


Anmelden zum Antworten