Ich bin da gestern auf ein etwas seltsames Problem gestoßen: Ein Programm wird "einfach so" beendet. So, als würde man ein halt; im Code stehen haben. Da das aber nicht der Fall ist, habe ich etwas gesucht und bin zum Ergebnis gekommen, dass es während MyObjectList.Sort(MyCompareFunction) zu einem Stackoverflow kommt, in dessen Folge das Programm einfach "verschwindet". Ganz still und heimlich. Kein "Plöng" mit toller "ErrorError"-Messagebox, kein madExcept-Fehlerbehandlungsdialog, nichts.

Eine Endlos-Rekursion würde ich da erstmal ausschließen. Warum der Stack trotzdem zu voll wird, muss ich noch mal genauer klären. Meine Frage ist aber grundlegender Natur.

Da ich MadExcept in der Anwendung benutze, wundert es mich jetzt erstmal, warum die Anwendung sich still und heimlich verabschiedet, und kein entsprechendes Fenster mit "Bugreport senden" kommt. Ich habe diesmal das "Glück", dass der Fehler leicht reproduzierbar ist und somit per durchsteppen gefunden werden kann, aber wenn der Fehler nur sporadisch auftreten würde, und dann auch zufällig nicht bei mir hätte ich bei dem Ding ganz schlechte Karten.

Vielleicht kann mir ja mal jemand mit Grundlagenwissen da auf die Sprünge helfen.

(Bis das geklärt ist: In der Coverflow-Ansicht bei Nemp bei umfangreichen Sammlungen nicht die ID3-Tags derart bearbeiten, dass sich z.B. der Interpret ändert, wenn das Coverflow danach sortiert ist. )

Kann es sein, dass du diese Methode in einem eigenen Thread aufrufst?
Wenn in Threads was schief geht, können diese keine Meldung anzeigen (nur der Hauptthread), sondern fliegen u.U. komplett ab.

Wäre jetzt meine einzige Idee.

Stack Overflow ist sowas auch immer ganz beliebt ...

Hängt damit zusammen, dass die Sort-Methode von Delphi IIRC QuickSort benutzt und der im Worstcase Quadratischen Speicherverbrauch auf dem Stack hat. MErgeSort wäre hier besser, hätte aber u.U. genau das gleiche Problem.

Warum er einfach so wegcrasht: Weiß ich auch nicht genau, aber soweit ich das beim Schreiben des ODbgIntf mitbekommen hab, wird unter manchen Umständen vom Betriebssystem eine Reihe bestimmter Funktionen nicht mehr aufgerufen, da entweder:
- Der Error Stack Frame beschädigt ist oder nicht untergebracht werden kann (Während eines Stack Overflows wird ein Sekundär-Stack angelegt)
- Eine Nested Exception aufgetreten ist, bei der der Exception-Handler von Windows "auf Nummer sicher" geht und die Anwendung einfach killt.

Hat man nun noch Threads kommt zusätzlich hinzu, dass für jeden Thread ein eigener Stack reserviert wird. Dieser ist für Sekundärthreads AFAIR um einiges kleiner (kann man aber in der Anwendung setzen), weshalb Threads i.d.R. nicht tief verzweigen sollten.

HTH.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

So. Ich glaube, ich habs.

Threads: Wäre mir sehr peinlich, wenn das die Ursache gewesen wäre. Das war es nicht.

Ich habe es geschafft, den Fehler auch mit einer kleinen Library zu reproduzieren. Das wiederrum heißt: Mit Worst-Case-Quicksort hat der Fehler nichts zu tun. Tatsächlich kommen diverse Fehler zusammen, die dafür sorgen, dass eine Liste generiert wird, die mit der "richtigen" Compare-Funktion den Delphi-Quicksort in eine Endlos-Rekursion schickt.

Das genauer zu erklären würde etwas länger werden - ich belasse es dabei. Ganz kurz: Die Compare-Funktion definiert ein bestimmtes Element als "am kleinsten". Unabhängig vom anderen Wert. Normalerweise sollten die Elemente in der Liste eindeutig sein, d.h. das stellt kein Problem dar. Leider habe ich "das kleinste" durch eine unübersichtliche Fehlerkette doch zweimal in der Liste drin, was dann zu ein oder zwei unnötigen Vertauschungen führt.

Gausi hat folgendes geschrieben :

Ich bin da gestern auf ein etwas seltsames Problem gestoßen: Ein Programm wird "einfach so" beendet. So, als würde man ein halt; im Code stehen haben. Da das aber nicht der Fall ist, habe ich etwas gesucht und bin zum Ergebnis gekommen, dass es während MyObjectList.Sort(MyCompareFunction) zu einem Stackoverflow kommt, in dessen Folge das Programm einfach "verschwindet". Ganz still und heimlich. Kein "Plöng" mit toller "ErrorError"-Messagebox, kein madExcept-Fehlerbehandlungsdialog, nichts.

Der Grund ist relativ einfach: Die Routinen zur Fehlerbehandlung benoetigen selbst Speicher (zum Ablegen von Objekten und Strings) und Stack (fuer lokale Variablen und Funktionsaufrufe bzw. deren Ruecksprungadressen). Wenn eins von beidem nicht mehr zur Verfuegung steht, kann die Fehlerbehandlung schiefgehen. Delphi versucht durch vorbeugende Speicheranforderung beim Programmstart das Problem mit fehlendem Speicher zu beheben, so dass ein EOutOfMemory meistens behandelt und angezeigt wird. Mit einem Stack Overflow kommt es aber nicht so gut klar, den bekommt man meist nur gemeldet, wenn das Programm im Debugger laeuft.

twm

dummzeuch hat folgendes geschrieben :

Mit einem Stack Overflow kommt es aber nicht so gut klar, den bekommt man meist nur gemeldet, wenn das Programm im Debugger laeuft.

Mit einem Hook an der richtigen Stelle bekommt man ihn aber trotzdem oftmals noch zu Gesicht, selbst ohne Debugger. Dafür crasht einem aber oftmals das Programm weg, weil einem dann exakt 16 KB Stack zur Verfügung stehen, was für Delphi-Verhältnisse VIEL zu wenig ist. Besagtes ODbgIntf konnte es, hatte aber auf Grund des Hooks ein paar andere Problemchen (Vista-tauglichkeit hab ich nie getestet, geh aber mal davon aus, dass es nicht lief).

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Guter Artikel über Exception Handling aus Win32-Systemsicht: www.microsoft.com/ms...ption/Exception.aspx

Wenn Windows nicht mehr weiter weiss, macht er ExitProcess.

A Crash Course on the Depths of Win32 Structured Exception Handling hat folgendes geschrieben:

If UnhandledExceptionFilter returns EXCEPTION_EXECUTE_HANDLER, the _except block in BaseProcessStart executes. All the _except block code does is terminate the current process by calling ExitProcess. Thinking about it for a second, this makes sense; it's common knowledge that if a program causes a fault and nobody handles the fault, the system terminates the process. What you're seeing in the pseudocode is exactly where and how this happens. There's one final addition to what I've just described. If the thread that faulted is running as a service and is for a thread-based service, the _except block code doesn't call ExitProcess—it calls ExitThread instead. You wouldn't want to terminate the entire service process just because one service went bad.

Ob wirklich das geschieht sei dahingestellt, aber es ist eine Möglichkeit.

delfiphan hat folgendes geschrieben :

Ob wirklich das geschieht sei dahingestellt, aber es ist eine Möglichkeit.

Jap, genau das passiert. Selber schon durch mehrfaches Debugging von Endlos-Rekursionen und anderen Exceptions nachgeprüft. Insbesondere das mit den API-Aufrufen

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.