Seltsamer Programmfehler (Delphi schließt sich)

[blackdrake]

Hallo,

ich habe ein ziemlich nerviges Problem... ich habe während einer VCL Entwicklung festgestellt, dass sich das Programm mitsamt Delphi IDE schließt - ohne jegliche Fehlermeldung.

Für dieses Projekt (da hier ein besonderer Wert auf Abwärtskompatibilität gelegt werden muss) nutze ich Delphi 6 und Windows 2000 SP4.

Folgenden Quellcode habe ich erzeugen können, der das Problem reproduziert. Es sind viele andere Variationen möglich, aber alle haben sie gemein, dass in einem OnTimer-Ereignis ein Thread aufgerufen wird.

Delphi-Quellcode:

{ TMySendingThread }

type
  TMySendingThread = class(TThread)
  protected
    procedure Execute; override;
  end;

procedure TMySendingThread.Execute();
begin

end;

{ TForm2 }

procedure TForm2.FormCreate(Sender: TObject);
begin
  x := TTimer.Create(Self);
  x.Interval := 100; // Desto kürzer die Zeit, desto schneller stürzt Delphi ab
  x.OnTimer := MyTimer;
end;

procedure TForm2.MyTimer(Sender: TObject);
var
  z: TThread;
begin
  // Dieser Thread bringt Delphi nach mehreren Timer-Ereignissen zum Absturz!
  // (Obwohl der Thread ja gar nix macht!)
  // Im Debugger schließen sich die Anwendung UND Delphi einfach so (Delphi 6, Windows 2000 SP4)
  // Keine Fehler-Meldung und auch Delphi fragt nicht, ob man den Quelltext speichern will etc
  // Außerhalb des Debuggers gibt es keine Auffälligkeiten. Anwendung und Windows laufen stabil
  z := TMySendingThread.Create(true);
  z.FreeOnTerminate := true;
  z.Resume;
end;

end.

Starte ich die Anwendung außerhalb des Debuggers scheint alles unauffällig zu sein. Betriebssystem und Anwendung laufen stabil.

Lediglich Delphi schließt sich (Egal ob der Quelltext gespeichert wurde oder nicht!) einfach so, wenn die Anwendung im Debugger gestartet wird.

Tritt das Problem bei neueren Delphi Versionen auch auf? Ist es ein Delphi-Bug? Oder stoße ich durch den Thread im Timer gegen irgendwelche Betriebssystem-Grenzen/Bugs?

Über Hinweise wäre ich sehr Dankbar.

Gruß
blackdrake

[Luckie]

Du erzeugst alle 100 Millisekunden einen neuen Thread? Das ergibt 600 Threads in einer Minute. Ich kann dir zwar nicht erklären, warum das Programm in der IDE abstürzt und ohne IDE nicht. Aber ich kann dir sagen, dass das bestimmt nicht gut ist, was du da machst und mit Sicherheit nicht die Lösung deines Problems.

[Dawn87]

Naja, der wird doch sofort wieder freigegeben, da FreeOnTerminate True ist und im Execute nichts geschieht.

Was ich mir vorstellen könnte ist, dass dies wirklich ein Fehler im Debugger ist. Bei jeder Threaderstellung bekommt der Debugger eine Benachrichtigung und da es irgendwann zuviel wird, kommt der Durcheinander. Wäre eventuell einen QC-Eintrag Wert?!

Mit Delphi XE2 funktioniert das übrigens in der IDE ohne Absturz.

Grüße

[Luckie]

Zitat von Dawn87:

Naja, der wird doch sofort wieder freigegeben, da FreeOnTerminate True ist und im Execute nichts geschieht.

Trotzdem muss Windows für jeden Thread 2 MB Speicher für den Stack des Threads im Adressraum des Prozesses anlegen für jeden neu erzeugten Thread. Auch wenn kein produktiver Code ausgeführt wird, hechelt Windows da ganz schön hinter her. Und ich gehe mal davon aus, dass irgendwann noch Code in die Execute Methode der Thread-Klasse ausgeführt werden soll. Oder soll hier ein Bug in der IDE aufgedeckt werden, der eigentlich so nie zum Tragen kommt?

[himitsu]

Du könntest auch mal ins OnTerminate deiner Threads Folgendes einfügen:

Delphi-Quellcode:

if Assigned(FatalException) then
  ShowException(FatalException as Exception);

Mal sehn ob was passiert.

[Mavarik]

Und das Thread Object liegt auf dem Stack weil lokal definiert...

Das ist doch nicht mehr gültig wenn die Timer Procedure beendet wird.. Oder?

Mavarik

[jaenicke]

Zitat von blackdrake:

Delphi-Quellcode:

  z := TMySendingThread.Create(true);
  z.FreeOnTerminate := true;
  z.Resume;

Lass den Blödsinn mit suspended erzeugen und Resume, dann wird es wahrscheinlich auch keine Probleme mehr geben...

FreeOnTerminate + Resume ist eine Kombination, bei der Probleme vorprogrammiert sind. Nicht ohne Grund ist Resume mittlerweile als deprecated markiert.
Eins der möglichen Probleme: Resume ist noch nicht fertig, wenn der Thread schon fertig ist und freigegeben wird. Rumms...

[Furtbichler]

Also ich halte das nicht für Blödsinn, denn nichts anderes passiert, wenn man den Thread mit 'CreateSuspended=False' instantiiert: Er wird erst 'Suspended' erzeugt (in jedem Fall) und im AfterConstruction ggfs. per 'Resume' aufgeweckt.

Die Resume-Methode ist deprecated, weil viele Programmierer damit Threads zwischendurch anhalten bzw. wieder weiterlaufen lassen. Und DAS ist eine schlechte Idee.

Edit:... oh, es ist doch nicht geschickt, so wie es umgesetzt ist, ich bezweifle aber, das das Probleme bereitet.

Ich mache das mit dem Initialisieren immer im abgeleiteten Konstruktor:

Delphi-Quellcode:

Constructor TMyThread.Create;
Begin
  inherited Create(True);
  InitializeMyThreadStuff();
  Resume;
End;

und das ist so überflüssig (aber deklarativ).

[himitsu]

Zitat von Furtbichler:

Ich mache das mit dem Initialisieren immer im abgeleiteten Konstruktor:

Delphi-Quellcode:

Constructor TMyThread.Create;
Begin
  inherited Create(True);
  InitializeMyThreadStuff();
  Resume;
End;

Wozu das Resume?
Der Thread wird doch sowieso immer erst nach der Create-Methode gestartet. (wenn man es nicht suspended startet)

[Furtbichler]

Hi,
Eben. Ich schrieb ja, ...

Zitat von Furtbichler:

...das ist so überflüssig (aber deklarativ).

Mit "deklarativ" meine ich, das der Code beschreibt, was (sowieso im Hintergrund) geschieht.

Und, ich muss zu meiner Schande gestehen, das ich eben erst (durch Studium des Classes-Quellcodes) entdeckt habe, das meine Vorgehensweise gut gedacht aber vollkommen überflüssig ist.

Los, nun hack noch weiterauf meinem Unvermögen rum.
Es regnet sowieso.
Das Wochenende ist versaut.

Muhuuuhhhuuuu.