Stackoverflow finden - wenn es denn einer ist

[Medium]

Hallo DP,

ich bin auf der Suche nach dem Grund für ein ekelhaft schlüpfriges Problem mit einem Programm von mir. Es ist (bzw. war) in Delphi 7 geschrieben und lief über Jahre auf WinXP ohne Probleme im 24/7 Einsatz. Der Kunde hat jetzt neue PCs und dort Win7 64 drauf.
Mein Programm hat scheinbar auch dort funktioniert, ist aber nach recht verlässlich 15-20 Minuten abgestürzt. Windows meldete fast immer nur "ein Problem" und bat mir an es abzuschießen. Ein Mal aber kam ein Infofensterchen, wo der Kunde abgelesen hat dass der Absturz in der "usp10.dll" aus dem SysWOW64 Ordner gemeldet wurde.
Da ich das Programm schon länger gerne zumindest in einer wenig neuere IDE haben wollte, habe ich mir die Zeit genommen es auf D2007 zu portieren. (Bei noch neuer haben wir Probleme mit 3rd-Party Komponenten.) Das Kompilat mit D2007 funktionierte ebenfalls erst problemlos, aber nach 15-20 Minuten wieder Absturz. Dieses Mal habe ich zumindest ein Infofenster gehabt, und laut dem soll es nun in der ntdll.dll passiert sein, mit Anwendungsfehlercode 0xc000005.

Der kann leider ein riesen Haufen von Ursachen haben, da es prinzipiell erstmal nur eine Zugriffsverletzung aussagt... Defekter Speicher wird gerne genannt, jedoch passiert dies auf 3 Panel-PCs in exakt gleicher Weise, so dass ich hieran zweifle. Zumal andere Programme klaglos arbeiten. Andere Stellen im Netz sprechen von Stackoverflows, und dass Windows Programme die solche regelmäßig produzieren in eine Art fehlertoleranten Modus gesetzt werden, bei zu vielen Vorkommnissen pro Stunde es aber dann doch abschießt. (Nie gehört zuvor.) Und was mir auffiel: Es sind oftmals Spiele die o.g. Code produzieren, aber nicht in der ntdll.dll sondern meist in der eigenen EXE. Mein Programm ist jedoch eine ganz normale VCL Anwendung, sogar mit nur einem einzigen Fenster.

Ich habe dann mal alle Methoden in meinem Programm in try..except Blöcke gepackt, in der Hoffnung dass ich dann einen besser lokalisierbaren Fehler bekomme. Zudem habe ich Stack-Frames, Bereichs- und Überlaufprüfung aktiviert. Keine der Maßnahmen schlugen an, und nach 15-20min ist mein Programm wieder mit dem gleichen Fehler abgeschmiert. Kann die Ursache dann eigentlich überhaupt noch in meinem Code liegen? Wo kann ich anfangen nach der Ursache zu suchen? (Eurekalog o.ä. scheitert im Moment erstmal daran, dass der Kunde recht weit weg ist und ich erst in 1-2 Wochen dazu kommen werde dort hin zu fahren um weitere "live-tests" zu machen. Ich würde aber gerne im Vorfeld schon mal etwas tun.)

Wo kann man da jetzt noch ansetzen? (Leider kann ich auf den PCs beim Kunden kein Delphi installieren um durchzusteppen oder auf einen debugbaren Break zu hoffen.)

[haentschman]

Moin...:P

Zitat:

Leider kann ich auf den PCs beim Kunden kein Delphi installieren um durchzusteppen oder auf einen debugbaren Break zu hoffen.

Da der Fehler "verläßlich" kommt, könntest du mit Remote Debugging was anfangen? Das erfordert keine Delphi Installation.

[zagota]

- Schon mal mit MadExcept laufen lassen?
- Ab Win7 gibt es für Anwendungen ein Kompatiblitätsmodus, den für dein Programm schon aktiviert?

cu

[Bjoerk]

Bei StackOverflow denke ich im allg. zuerst an große lokale stat. Arrays oder an Rekursionen.

[Lemmy]

Zitat:

Zitat von Medium (Beitrag 1326242)

(Eurekalog o.ä. scheitert im Moment erstmal daran, dass der Kunde recht weit weg ist und ich erst in 1-2 Wochen dazu kommen werde dort hin zu fahren um weitere "live-tests" zu machen. Ich würde aber gerne im Vorfeld schon mal etwas tun.)

Eurekalog, MadExcept und co. sind genau für den Fall gedacht, dass man nicht selbst an dem Rechner sitzen kann....

[Der schöne Günther]

Wahrscheinlich liege ich falsch, aber maxExcept und alles helfen einem doch auch nicht weiter wenn der globale Exception-Handler direkt die gesamte Anwendung killt, oder?

Beispiel: Im

Delphi-Quellcode:

OnTerminate

-Handler eines Threads tritt eine Exception auf:

Delphi-Quellcode:

procedure TForm3.FormCreate(Sender: TObject);
var
   thread: TThread;
begin
   thread := TThread.CreateAnonymousThread(
      procedure()
      begin
         //
      end
   );
   thread.OnTerminate := handleThreadTerminate;
   thread.Start();
end;

procedure TForm3.handleThreadTerminate(Sender: TObject);
begin
   raise EProgrammerNotFound.Create(EmptyStr);
end;

Können Lösungen wie madExcept so etwas noch loggen?

[jobo]

Was macht denn Dein Programm?
Wenn es iterativ Speicher konsummiert, kann man dem ja nachgehen und aus den gleichen Sourcen ein Testprogramm machen, das nichts anderes tut, natürlich mit Protokollierung.

"neue Rechner" müssen auch nicht unbedingt ok sein, nur weil andere Software läuft. Der Kunde könnte mit eine Linux Live CD booten und einen Memtest machen.

[zagota]

Findet sich in der Windows Ereignisanzeige ein Hinweis?

cu

[Medium]

@Lemmy: Das ist wohl richtig, aber leider muss ich dort trotzdem hin um eine mit diesen Tools kompilierte Version zu installieren. (Leider kein Fernzugriff, daher ist auch Remote-Debugging so eine Sache.)

@Günther: Genau das habe ich mich auch gefragt. Wenn sämtliche try..excepts unbeeindruckt bleiben (ich habe wirklich stumpf um ALLE Methoden von begin bis end ge-try-ed), habe ich da auch Zweifel.

@jobo: Gleich bei 3 PCs (von Siemens, die ihre PCs in der Regel vorm Ausliefern diversen Stresstests unterziehen)? Klar, nichts ist unmöglich, aber das wäre schon irre. Der Speicherverbrauch bleibt relativ konstant. Das Programm lief ja sogar schon 2 Jahre (identisches Kompilat auch probiert) auf den alten PCs dort ohne Mucken.

@zagota: Ja, dort wird der o.g. Fehlercode mit Bezug auf mein Programm und die ntdll.dll protokolliert. Leider sonst keine weiteren hilfreichen Infos, und ich kann leider keinen genaueren Dump produzieren ohne vor Ort zu sein. Im selben Eintrag war auch noch ein Verweis auf "0xffffbaad" (Unter "P4" oder so), welches mir bekannt vorkam. Leider produzierte Google bei einer kombinierten Suche nach dem o.g. Code und diesem keine erkennbar relevanten Ergebnisse, und die Ursachen blieben in den meisten Foren im Dunkeln. Oftmals wurde das betroffene Programm neu installiert oder geupdated womit der Fehler verschwand, aber eine konkrete Ursache fand ich nicht. Leider habe ich diese Option nicht =)

Den Kompatibilitätsmodus habe ich noch nicht versucht. Leider krankt aber auch das daran, dass ich das erst machen kann wenn ich wieder Zeit habe da hin zu fahren. (Leider kein kundiges Personal vor Ort, alles Anlagenfahrer die schon mit der bloßen Existenz eines PCs an ihrem Arbeitsplatz überfordert sind.) Zumal es wie gesagt auf mindestens einem anderen Win7 64 PC (beim selben Kunden aber in einem anderen Werk) funktioniert.

Arrays kommen nur sehr vereinzelt vor, und sie sind alle statisch. Das war auch meine erste Idee, vergessen zu sagen. Sorry! Das größte ist 4096 Bytes lang, und es gibt keine Methode die mehrere Arrays nutzt. Ansonsten werden sowohl in Parametern als auch lokalen Variablen ausschließlich elementare Datentypen oder Objekte verwendet. Mit der Ausnahme von einer Hand voll Strings, die ich aber auch mit einer Längenprüfung versehen habe, und die ja ohnehin eigentlich auf dem Heap landen sollten. Es gibt nichtmals von mir erstellte Threads, alles nur im Main-Thread.

Es gibt eine Operation die per Timer zyklisch läuft. Es wird mit einer SPS via Sockets kommuniziert. Dieses Modul setzen wir allerdings in praktisch identischer Form in zig Programmen bei diversen Kunden auf allen möglichen Windows-Versionen seit 10+ Jahren ein, und hatten dieses Problem noch nicht.
Es werden in diesem Fall sogar vergleichsweise mickrige Datenpaketchen ausgetauscht, und die Buffer werden ebenfalls bzgl. ihrer Länge überprüft. Wenn es ein "normaler" Stack-Overflow wäre, bin ich es auch eigentlich gewohnt eine saubere Meldung der RTL zu bekommen, kein "wortloses Wegschießen".

[himitsu]

Zitat:

Delphi-Quellcode:

procedure TForm3.FormCreate(Sender: TObject);
var
   thread: TThread;
begin
   thread := TThread.CreateAnonymousThread(
      procedure()
      begin
         //
      end
   );
   thread.OnTerminate := handleThreadTerminate;
   thread.Start();
end;

procedure TForm3.handleThreadTerminate(Sender: TObject);
begin
   raise EProgrammerNotFound.Create(EmptyStr);
end;

Das ist aber ein vollkommen korrektes Verhalten, wenn tritt in einem Thread eine Exception auf und rauscht bis zum Windows durch, dann beendet Windows nunmal den kompletten Prozess.
Es ist also ganz normales Verhalten, da TThread nur das Execute per Try-Except absichert und in OnTerminate diese Exception bereit stellt.
Wer sollte denn Die Exception von OnTerminate bekommen, wenn danach nichts mehr kommt? Also gibt es keinen Grund diese Exception abzufangen.

Leider ist die RTL bissl blöd, dass sie diese Exception einfach verschluckt, wenn keiner in OnTerminate darauf reagiert (was fast nie gemacht wird), womit also eigentlich TThread diese Exceptions total falsch behandelt.