Hallo,
mein ziemlich großes Programm, das ich übernommen habe,
a) läuft gut und stabil, wenn ich es mit Debug erstelle (einschl. QtCore4d.dll)
b) stürzt ca jedes 4. Mal ab ("funktioniert nicht mehr"), wenn ich es mit Release (einschl QtCore.dll) erstelle.
Woran könnte das liegen ?
Gruß Christoph
Wieso läuft mein Programm
-
ChristophHaenel
- Beiträge: 17
- Registriert: 10. Februar 2011 18:30
Das ist aus der Ferne kaum abzuschätzen.. nur zwei Hinweise dazu:
- Evt. liegt noch irgendwo im Einzugsbereich des Betriebssystems noch eine andere QtCore.dll rum.. für einen Test könntest du den "dependency walker" verwenden
- Softwarefehler mit Pointern können sich auch so zeigen. Die sind im Nachhinein äusserst schwierig zu finden. Unter Windows kenne ich mich nicht so aus.. unter Linux gäbe es "valgrind" für solche Fälle...
hth!
- Evt. liegt noch irgendwo im Einzugsbereich des Betriebssystems noch eine andere QtCore.dll rum.. für einen Test könntest du den "dependency walker" verwenden
- Softwarefehler mit Pointern können sich auch so zeigen. Die sind im Nachhinein äusserst schwierig zu finden. Unter Windows kenne ich mich nicht so aus.. unter Linux gäbe es "valgrind" für solche Fälle...
hth!
genau jedes 4.te mal, oder nur so ca. ?
Isses reproduzierbar, also genau wenn ne folge von aktionen machst ?
Dann koennte es sein, das irgendwo ueber speichergrenzen hinausschreibst, und dich im Debug die Guards retten.
Isses eher mehr wie willkurlich, iss ne racecondition gegen irgendwas meist noch im spiel ... also fehler tritt nur auf, wenn irgendwas schnell genug laeuft ...
Aber Ursache kann am ende viel sein ... wird wohl eher auf debuggen im nichtdebug modus hinauslaufen
also codabschnitte steuck fuer stueck wegschalten, um einzugrenzen wo der fehler ist ...
Ciao ...
Isses reproduzierbar, also genau wenn ne folge von aktionen machst ?
Dann koennte es sein, das irgendwo ueber speichergrenzen hinausschreibst, und dich im Debug die Guards retten.
Isses eher mehr wie willkurlich, iss ne racecondition gegen irgendwas meist noch im spiel ... also fehler tritt nur auf, wenn irgendwas schnell genug laeuft ...
Aber Ursache kann am ende viel sein ... wird wohl eher auf debuggen im nichtdebug modus hinauslaufen
also codabschnitte steuck fuer stueck wegschalten, um einzugrenzen wo der fehler ist ... Ciao ...
-
ChristophHaenel
- Beiträge: 17
- Registriert: 10. Februar 2011 18:30
Nicht genau jedes 4. Mal, sondern circa jedes 4. Mal, aber nie seltener als jedes 10. Mal. Leider nicht gut reproduzierbar, obwohl ich die Transaktionen genau wiederholen kann.
Speicherfehler ? Ich finde nur new's, keine mallocs im Code. Das Programm ist von einem sehr ordentlichen Programmierer. Allerdings durchschaue ich es nicht.
Wisst ihr einen Mechanismus, um den Programmzustand unmittelbar _vor einem Absturz zu protokollieren? Ist der "Dependenc Walker" dafür geeignet ?
Speicherfehler ? Ich finde nur new's, keine mallocs im Code. Das Programm ist von einem sehr ordentlichen Programmierer. Allerdings durchschaue ich es nicht.
Wisst ihr einen Mechanismus, um den Programmzustand unmittelbar _vor einem Absturz zu protokollieren? Ist der "Dependenc Walker" dafür geeignet ?
Dependency walker nimmt man um zu sehen ob die nötigen Libraries verfügbar sind.
"new" schützt vor Torheit nicht (jedenfalls nicht gegenüber *alloc).
Du suchst wohl nur einen Debugger. Debugger anwerfen, Executable starten, Programm benutzen, auf Crash warten, Callstack anschauen.
Du kannst dir sicher auch ein Script bastelen, das dir das alles automatisch acht, so dass du nur auf ein Desktop-Icon klicken musst (wenn dir der Aufwand zu hoch und die Crashfrequenz zu niedrig ist).
"new" schützt vor Torheit nicht (jedenfalls nicht gegenüber *alloc).
Du suchst wohl nur einen Debugger. Debugger anwerfen, Executable starten, Programm benutzen, auf Crash warten, Callstack anschauen.
Du kannst dir sicher auch ein Script bastelen, das dir das alles automatisch acht, so dass du nur auf ein Desktop-Icon klicken musst (wenn dir der Aufwand zu hoch und die Crashfrequenz zu niedrig ist).