Zitat von Captnemo:

Wenn ich bei ComThreadList.Delete(i) eine Haltepunkt setze, und alle im Einzelschritt durchgehe, dann lande ich in der Unit "System.Classes" in der Funktion "TThread.destroy".
Das kommt aber wahrscheinlich durch den Aufruf von .Free (2 Zeilen drüber).

Das kommt eher daher, daß das Delete auch gleichzeitig die Instanz freigibt, die dann natürlich nicht mehr existiert. Lass doch mal das Free zwei Zeilen drüber weg.

Okay, das funktioniert Danke Uwe.

Allerdings besteht mein ursprüngliches Problem immer noch.
Jetzt habe ich mir mal das MADExcept heruntergeladen und auch in den madexcept Settings aktiviert. Meine Exe wird auch größer, und jetzt sollte doch eigentlich bei einer Exception ein Fenster mit Debuginfo's kommen. Allerdings bekomme ich nach wie vor entweder die Fehlermeldung von Windows, oder er geht ins Debugging der IDE. Muß man noch was anderes machen, damit madexcept die Exception abfängt?

Zitat von Captnemo:

Jetzt habe ich mir mal das MADExcept heruntergeladen und auch in den madexcept Settings aktiviert. Meine Exe wird auch größer, und jetzt sollte doch eigentlich bei einer Exception ein Fenster mit Debuginfo's kommen. Allerdings bekomme ich nach wie vor entweder die Fehlermeldung von Windows, oder er geht ins Debugging der IDE. Muß man noch was anderes machen, damit madexcept die Exception abfängt?

Der IDE-Debugger hat Vorrang. Wenn du das Programm dann in der IDE weiterlaufen lässt, sollte madExcept zuschlagen. Oder einfach ohne Debugger starten.

Wenn Windows die Exception fängt, dann müsste man das mal genauer untersuchen, wo die Exception hochkommt. Hast du alle Checks (Range checking, Overflow checking) aktiviert?

Okay, das mit den madexcept läuft jetzt. Ich habe eine bugreport, aus dem ich selbst leider nicht so viel herauslesen kann. Ich häng den mal an Anhang dran, vielleicht kann jemand etwas daraus erkennen.

Wenn ich dann in der madException auf Continue Application klicke, läuft meine Anwendung scheinbar weiter, bis ich der Mainform mal wieder den Focux spendiere.

Entweder du sagst der Objektliste die soll das löschen (OwnsObjects) und selber löschst du das nicht mehr,
wobei hier das Delete die TThread-Instance löscht.

Aber wenn du das unbedingt selber löschen willst, dann darf entwedet die Liste das nicht automatisch löschen (kein OwnsObjects)
oder du mußt den "ungültigen" Zeiger via TObjectList.Extract rausholen.

Ich habe jetzt OwnObjects:=False und lösche das Object jetzt selber. Das Free hab ich rausgenommen und so funktioniert es jetzt auch.
Aber mein Ursprüngliches Problem ist noch da und das mit dem madexcept will auch nicht funktionieren (Wär ich heut bloß im Bett geblieben)

Zitat von Captnemo:

Ich habe jetzt OwnObjects:=False und lösche das Object jetzt selber. Das Free hab ich rausgenommen und so funktioniert es jetzt auch.
Aber mein Ursprüngliches Problem ist noch da und das mit dem madexcept will auch nicht funktionieren (Wär ich heut bloß im Bett geblieben)

Du hast jetzt das Free weggemacht und das OwnObjects auch und das FreeOnTerminate ist ebenfalls nicht aktiv?
Es gibt also nur noch das Delete in der Liste.

Nja, dann hast du den Thread-Zeiger nun aus der Liste, aber die Thread-Instanz gammelt als Speicherleck immernoch im Programm rum.
Einwas davon mußt du schon noch machen (nur Eines und nicht Mehreres).

Sorry, Ownobjects ist natürlich auf True. Hatte mich vertippt.

Guten Morgen,

neuer Tag, neues Glück.

Da mein ursprünglicher Fehler immer noch existiert, steige ich an dieser Stelle noch mal ein.

Wie bereits gesagt, wird eine Exception ausgelößt, wenn mein Thread mit dem TCP-Client (TWSocket von ICS) beendet wird bzw. beendet ist, und ich anschließen der Mainform den Focus geben, z.B. durch anklicken.
Was dann im Detail passiert kann ich schwer sagen. Aber ich nehme mal an, dass Windows sicherlich eine Window-Message schickt, deren Verarbeitung dann, aus welchen Gründen auch immer, fehlschlägt.

In meinem Programm fange ich im Grunde keinerlei Messages ab, bis auf eine einzige, die mein Thread an die Mainunit schickt wenn er sich beendet, aber die habe ich erst später hinzugefügt. Der Fehler war schon vorher da.
Leider weiß ich mir nicht zu helfen.

Wenn ich den Thread nicht erzeuge, und dem zur Folge auch nicht beende, tritt natürlich kein Problem auf.

Zu der Exception springt mir die der Debugger der IDE an folgende Stelle:

zusammenfalten · markieren

Delphi-Quellcode:

{ Standard window procedure }
function StdWndProc(Window: HWND; Message: UINT; WParam: WPARAM; LParam: WPARAM): LRESULT; stdcall;
{$IF Defined(CPUX86)}
{ In    ECX = Address of method pointer }
{ Out   EAX = Result }
asm
        XOR EAX,EAX
        PUSH EAX
        PUSH LParam
        PUSH WParam
        PUSH Message
        MOV EDX,ESP
        MOV EAX,[ECX].Longint[4]
        CALL [ECX].Pointer
        ADD ESP,12 //<- Genau hier hin.
        POP EAX
end;

Ich habe mal eine Screenshot von der IDE an dieser Stelle gemacht und angehängt. Vielleicht hat ja irgendjemand noch eine Idee, was ich machen könnte um dem Fehler auf die Spur zu kommen.

Meinen Thread häng ich auch noch mal dran, möglicherweise liegt der Fehler ja da drin.

Die Fehlerstelle ist hier eine Zeile vorher, denn leider zeigt der Debugger die Position der Rücksprungadresse an.

Der Fehler ist also in dem CALL aufgetreten, bzw. in der aufgerufenen Methode.

Zitat:

Aber ich nehme mal an, dass Windows sicherlich eine Window-Message schickt, deren Verarbeitung dann, aus welchen Gründen auch immer, fehlschlägt.

Dem würde ich mal zustimmen.

In welchem Thread-Kontext liegt das denn? (würde zwar MainThread vermuten, aber kann nicht schaden mal nachzusehn -> Thread-Status)