Stackoverflow finden - wenn es denn einer ist

[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 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?

[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.

[Perlsau]

Zitat von Medium:

Zumal es wie gesagt auf mindestens einem anderen Win7 64 PC (beim selben Kunden aber in einem anderen Werk) funktioniert.

Das ist doch wohl ein eindeutiger und unmißverständlicher Hinweis darauf, daß es an diesen drei Siemens-PCs liegen muß. Ich würde deinem Kunden daher einmal folgendes vorschlagen:

1. Ist der PC im anderen Werk, auf dem es funktioniert, ebenfalls von Siemens?
2. Besorgen Sie sich einen weiteren PC mit derselben bzw. gleichwertigen Ausstattung, jedoch nicht von Siemens.
3. Installieren Sie dort dasselbe Betriebssystem.
4. Installieren Sie dann meine Anwendung und lassen Sie sie laufen.
5. Wie lange läuft die Anwendung auf diesem vierten PC ohne Probleme?

Nach diesem Test rätst du dann deinem Kunden, die PCs an den Lieferanten zurückzugeben mit dem Hinweis, daß damit irgend etwas nicht in Ordnung sei.

[jobo]

Zitat von Medium:

@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.

Ich meine, gerade weil es 3 oder 5 neue Kisten eines Herstellers aus einer Bestellung/Charge sind, kann das vorkommen.
Wir hatten neulich einen "Schwung" Samsung Tablets, bei denen mittels eines Samsung Algorithmus (android) alle die gleiche DeviceID (UUID) bekamen, obwohl sie natürlich unterschiedlich sein sollte. Wäre wahrscheinlich nie aufgefallen, wenn man die Geräte stückweise bei verschiedenen Händlern gekauf hätte.

[Namenloser]

Wie kommst du eigentlich auf Stackoverflow? Was deutet konkret darauf hin?

Ich würde eher vermuten, dass du an irgendeine WinAPI-Funktion ein ungültiges Objekt übergibst, also z.B. einen ungültigen Pointer. Der Code in der ntdll versucht dann darauf zuzugreifen und es kracht. Weil es in der WinAPI kracht und nicht in deinem eigenen Programm, schlägt dein Exception-Handling nicht an und du kriegst auch keinen aussagekräftigen Call-Stack. Es muss kein Pointer sein, den du direkt übergibt. Der Pointer könnte sich auch in einem nicht korrekt initialisierten Struct verstecken. Das könnte auch erklären, warum es erst ab einer gewissen Windows-Version auftritt, weil Structs ja manchmal reservierte Felder enthalten, die erst ab einer späteren Version interpretiert werden. Vielleicht wird durch fehlende Initialisierung manchmal zufällig ein neues Flag aktiviert, welches es unter XP nicht gab, was dazu führt, dass ein anderes Feld plötzlich als Pointer interpretiert wird o.ä..

[Medium]

@himitsu: Ich habe aber doch gar keine Threads.

@Perlsau: Das wäre wohl die letzte und auch blödeste Lösung, weil mit mächtig Aufwand verbunden. Ich kann nur hoffen, dass sich der Kunde im Zweifelsfall darauf einlässt. Bevor ich diesen Schritt gehe würde ich aber gerne nichts unversucht lassen.

@jobo: Ja, normalerweise würde ich durchaus zustimmen. Aber Industrie-PCs sind ja gerade deshalb 3-4 mal so teuer wie vergleichbare Consumer-Hardware, weil sie intensiven Tests unterzogen werden. Jeder einzelne. Ausgeschlossen ist es damit zwar nicht, aber dass auf 3 PCs, egal welche Programme vorher gestartet sind, verlässlich immer nur mein kleines Tool genau immer an der gleichen Stelle den kaputten Speicher trifft... da muss selbst für IT-Maßstäbe schon viel Hexerei am Werk sein

@Namenloser: Stack-Overflow war in den von mir gefundenen Beiträgen im Netz das konsistenteste "Unterthema". Und ein Mal ist mein Programm auch wirklich mit dieser Meldung abgeschmiert! Also einfach das kleine Fensterchen, dass man von Delphi kennt: "Stapelüberlauf [OK]" (weiss nicht mehr ob auf Deutsch oder Englisch).
Ich selbst benutze keine direkten WinAPI Aufrufe, es läuft alles über die VCL. Wenn, dann müsste in dieser der Fehler liegen, und seit Jahren unbemerkt geblieben sein. Das ist wirklich ein total simples Programm. Keine Threads, bis auf Strings keine dynamischen Strukturen, keine WinAPI, keine Rekursionen, Standard-Projektoptionen, nur Pagecontrol, Listbox, Edits, Labels und Images auf dem Formular, ...nichts was traditionell zu einem Stack-Overflow führen sollte. Ich bin absolut baff.
Aber ich erkenne hier schon: Es scheint zumindest kein übliches Diagnose-Vorgehen zu geben in solchen Fällen. Muss ich den Kunden wohl vorerst vertrösten und später dann mal mit MadExcept/Eurekalog und/oder im Kompatibilitätsmodus laufen lassen, und hoffen dass hier was bei rum kommt. Geschlagen geben ist keine Option.

[himitsu]

Nja, irgendwe fing hier mit Thread an.

Zitat:

nach x minuten Absturz

Programmstarten, warten und dann einfach so peng?
(Timer?)

Oder macht der Benutzer da grade was?


Du kannst dein Programm mit Logging voll packen und dann schauen, wo dein Programm als Letztes vorbei kam und dann ab da weiter suchen.

[notAssertor]

@Medium, Knochen statt Fleisch

Schmiert das Programm auf allen PCs oder nur auf den Siemens-PCs ab?

Ist in das Programm eine Art XP-Manifest einkompiliert?

In diese beiden Richtungen würde ich zuerst rumstochern

VG

[jobo]

Zitat von Medium:

@jobo: Ja, normalerweise würde ich durchaus zustimmen. Aber Industrie-PCs

Ok, ich will das nicht tot reiten, aber dazu noch ein Hinweis:
Wenn es ein IndustriePC ist, verwendet der jenseits der üblichen verdächtigen Komponenten vielleicht auch andere spezielle Hardware (inkl. Treiber).
Diese Hardware (Steckkarte,.. whatever) hat- Industriepc hin oder her- per se den Nachteil, dass sie eben nicht Standard ist (Häufiger Einsatz, Reifung beim Kunden, .. Robustheit). Zufällig neulich ein Beispiel mitbekommen: USB Chips werden gern von Intel oder Renesas verbaut. Die Teilearbeiten mit völlig unterschiedlichem Verhalten bezüglich Powersave Modus. Intel macht es ganz "aggressiv", Renesas lässiger. Der Fehler geschah nun immer beim Wechsel in den Powersave Mode (USB seitig). Für den Anwender war das scheinbar zufällig bzw. von außen kein Anlass erkennbar. Die Komponente war etwas besonders teures, quasi "Industrieware". Vlt klingelt es da noch mal bei Dir, Stichwort "Powersave nach einer bestimmten Zeit" oder "teurer Industriepc"
Für mich wäre die Frage einfach nur: Wie einfach und billig kann ich oder der Kunde das ausschließen, statt es nur für "unwahrscheinlich" zu erklären.
Inwieweit hier Randbedingungen meines Beispiels mit Deinem Fall übereinstimmen, Thema Wahrscheinlichkeit, musst Du selbst beurteilen.