Hallo zusammen,

ich habe ein ziemlich merkwürdiges Phänomen, das ich mittlerweile schon fast für einen Bug in Delphi halten würde. Vielleicht kann ja mal der ein oder andere versuchen, das bei sich nachzustellen, um das Problem zu bestätigen. Vielleicht hat aber ja auch jemand eine Erklärung und alles ist viel einfacher als gedacht.

Hintergrund: In einem etwas komplexeren Projekt kam es plötzlich mitten in der Arbeit zu einem spontanen Programmabsturz, der so fies war, dass noch nicht mal der Debugger angesprungen ist, sondern sofort Windows verkündete "Dieses Programm funktioniert nicht mehr...". Zuerst dachte ich, ich hätte mir selbst irgendeine Falle gestellt, irgendwo den Speicher zerschossen, was weiß ich. Das übliche eben.

Mittlerweile konnte ich das Verhalten allerdings mit folgendem Allereinfachst-Projekt nachstellen, wo nun wirklich nichts mehr drin sein sollte, das den Speicher zerschießt. Es handelt sich hierbei nur um ein ganz einfaches Form mit einem Button und einem MouseMove-Ereignis:

zusammenfalten · markieren

Delphi-Quellcode:

unit main;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls;

type

  TForm1 = class(TForm)
    Button1: TButton;
    OpenDialog1: TOpenDialog;
    procedure Button1Click(Sender: TObject);
    procedure FormMouseMove(Sender: TObject; Shift: TShiftState; X, Y: Integer);
    function myDummyFunction: boolean;
  private
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
begin
  opendialog1.Execute;
end;

procedure TForm1.FormMouseMove(Sender: TObject; Shift: TShiftState; X, Y: Integer);
begin
  myDummyFunction;
end;

function TForm1.myDummyFunction: boolean;
begin
  Result:=false;
end;

end.

Sieht doch soweit erstmal einfach aus, oder? Nun muss man das Programm einfach nur starten, dann einmal auf den Button klicken, dann den Öffnen-Dialog wieder schließen und dann einfach den Mauszeiger über der Form belassen (nicht über dem Button) und eine Minute warten. Nach etwa einer Minute nämlich werden offenbar einige Bibliotheken entladen, die für den Öffnen-Dialog nötig werden. Bei diesem Entladen schmiert das Programm ab, wie oben beschrieben. Es gibt also keine Fehlermeldung, nur Windows, das einem sagt, dass es das Programm beenden muss. Meistens wird das Programm beendet und man kann mit Delphi weiterarbeiten, manchmal schmiert dann Delphi gleich mit ab.

Kein Problem tritt auf, wenn man das Programm ohne Delphi bzw. Debugger startet. Wenn es wie oben schon mal abgeschmiert ist und man es dann noch mal startet, dann läuft es manchmal auch durch, aber nicht immer. Wenn man es aber direkt aus einem sauberen Delphi startet, dann lässt sich das obige immer nachvollziehen.

System: D2009 Prof., Win7 Prof. 32Bit.

Ich wäre für Rückmeldungen sehr dankbar, wie das bei euch aussieht.

Als kleinen Service gibt es noch das Test-Projekt als Anhang.

Bis denn
Bommel

edit: Anhang korrigiert, siehe Post #4.

Da fehlt aber noch die "ALHintballoon.pas". Nach Auskommentieren derselben kann ich zumindest unter D2007 nichts Außergewöhnliches feststellen.

Konnte das unter D2010 auch nicht weiter nachvollziehen.

Habe aber ähnliche Probleme mit D2010 in Verbindungs mit Threads. Weiß bisher auch noch nicht genau woran es liegt. Wenn ich die Anwendung nich aus D2010 heraus starte funktioniert es wunderbar.

Zitat von DeddyH:

Da fehlt aber noch die "ALHintballoon.pas". Nach Auskommentieren derselben kann ich zumindest unter D2007 nichts Außergewöhnliches feststellen.

In der Tat, die fehlte und das könnte uns vielleicht auf die richtige Spur bringen. Ich habe die Datei oben im Anhang ergänzt, vielleicht tritt der Fehler ja jetzt bei euch auf.

Im eigentlichen Projekt verwendet ich eine Balloon-Komponente (TALHintBalloon), diese ALHintBalloon.pas ist nun allerdings nur noch eine kleine Rumpf-Unit. Sie ist entstanden, weil ich diese Balloon-Komponente zunächst als schuldige für meine Probleme vermutet habe, aber in der Unit alles so weit reduzieren konnte, bis eben nur noch dieser Rumpf übrig war.

Die Beobachtung von DeddyH konnte ich reproduzieren: Schmeiße ich bei mir die Unit auch komplett raus, dann läuft das Programm ohne Probleme nach dem Punkt, an dem die Bibliotheken entladen werden, weiter. Nehme ich sie wieder rein, dann schmiert es ab.

Nun wird in der Unit lediglich folgender Abschnitt wirklich ausgeführt:

markieren

Delphi-Quellcode:

  TALHintBalloonControl = class(TComponent)
    function CloseHintBalloon: boolean;
  end;
[...]
initialization
  bommelHelphHintBalloon:=TALHintBalloonControl.Create(nil);
finalization
  FreeAndNil(bommelHelphHintBalloon);
end.

Es wird also nur ein Objekt erzeugt. "CloseHintBalloon" hat hier auch keine Funktion und liefert immer false, wird aber ja gar nicht ausgeführt im vorliegenden Projekt.

Das einzig ungewöhnliche ist, dass die Komponente beim Create als Owner "nil" mitbekommt. Kann das denn die Ursache für die Probleme sein?

Bis denn
Bommel

statt nil mal application nehmen?

Zitat von Progman:

statt nil mal application nehmen?

Naja, mit Application ist es schlecht, weil das Ganze dann am Ende beim Freigeben zu einem Fehler führt.

Ich habe das Ganze nun noch einmal so umgebastelt, dass wieder alles in einer Unit steht, so dass nun also die ALHintBalloon.pas wirklich nicht mehr gebraucht wird. Außerdem ist nun das Form1 der Owner von der Komponente, die erzeugt wird, also auch daran kann es eigentlich nicht mehr liegen. Aber: Das Dingen knallt immer noch an der selben Stelle wie vorher. Fast jedes mal.

Insgesamt sieht der Code nun so aus (auch noch mal komplett im Anhang):

zusammenfalten · markieren

Delphi-Quellcode:

unit main;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls;

type
  TALHintBalloonControl = class(TComponent)
    function CloseHintBalloon: boolean;
  end;

  TForm1 = class(TForm)
    Button1: TButton;
    OpenDialog1: TOpenDialog;
    procedure Button1Click(Sender: TObject);
    procedure FormMouseMove(Sender: TObject; Shift: TShiftState; X, Y: Integer);
    function myDummyFunction: boolean;
    procedure FormCreate(Sender: TObject);
    procedure FormDestroy(Sender: TObject);
  private
    bommelHelphHintBalloon: TALHintBalloonControl
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

function TALHintBalloonControl.CloseHintBalloon;
begin
  Result:=false;
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
  opendialog1.Execute;
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
  bommelHelphHintBalloon:=TALHintBalloonControl.Create(self);
end;

procedure TForm1.FormDestroy(Sender: TObject);
begin
  FreeAndNil(bommelHelphHintBalloon);
end;

procedure TForm1.FormMouseMove(Sender: TObject; Shift: TShiftState; X, Y: Integer);
begin
  myDummyFunction;
end;

function TForm1.myDummyFunction: boolean;
begin
  Result:=false;
end;

end.

Außer, dass dieses Programm nichts sinnvolles erledigt kann ich daran absolut nicht ungewöhnliches entdecken. Also, selbst falls ihr den Fehler bei euch nicht 1:1 nachtsellen könnt: So etwas darf doch eigentlich nicht zu einem solchen Absturz führen, wie ich ihn hier immer wieder habe, oder? Oder mache ich in diesem einfachen Code irgendwas böses, was ich noch immer übersehe?

Bis denn
Bommel

PS: Bin erst mal weg vom Rechner - falls noch Fragen auftauchen, kann ich wahrscheinlich erst morgen reagieren...

Hast du alle Updates von D2009 installiert? Bei mir ist es so, dass es nicht zum Absturz kommt, aber nach circa einer Minute sich einige Threads (~20 an der Zahl) beenden. Vielleicht hat der Debugger einen Fehler und das wurde mit einem Update behoben?

Ich habe gerade noch mal sicherheitshalber nach Updates suchen lassen, aber da wurde nichts gefunden. Mein Delphi sollte also auf dem neuesten Stand sein (Updates 3+4 werden als installiert angegeben).

Da mir auch keine andere Erklärung einfällt, bleibt mir wohl nur der Glaube an einen Bug im Debugger in meinem Delphi. Hm.

Bis denn
Bommel

Hallo zusammen,

es ist zwar schon einige Zeit seit dem letzten Beitrag dieses Threads vorbei, aber ich habe genau dieses Problem in meiner Applikation.
Bei der Ausführung des von Bbommel am 30.03.2010 beigelgten Zip (MoveTest_153) passiert bei mir genau dieser Fehler.

Ist in der Zwischenzeit eine Lösung dazu aufgetaucht?

Im Anhang die Daten zu meiner Delphi-Installation

Bis denn
Franz