Delphi 12: Fehler mit Action := caFree

[WiWo]

Die Forms in meinem Projekt werden immer nur instanziert, wenn sie benötigt werden (also nicht im .DPR) und beim schließen wieder freigegeben. indem ich im FormClose-Event Action := caFree setze. Das mache ich seit 25 Jahren so durch alle Delphi-Versionen hindurch.
Mit Delphi 12 crasht es beim Schließen, wenn die Form größere Datenmengen enthält (nur dann!). Ist auch einfach nachzustellen. Kann jemand sonst noch diesen Effekt bestätigen?

unit Unit2;

interface

uses
Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls;

type
TForm2 = class(TForm)
Button1: TButton;
procedure Button1Click(Sender: TObject);
procedure FormClose(Sender: TObject; var Action: TCloseAction);
private
{ Private-Deklarationen }
public
{ Public-Deklarationen }
xxx: array[1..999999] of byte; // a lot of additional data in this object
end;

implementation

{$R *.dfm}

procedure TForm2.Button1Click(Sender: TObject);
begin
Self.Close;
end;

procedure TForm2.FormClose(Sender: TObject; var Action: TCloseAction);
begin
Action := caFree;
end;

[himitsu]

Nein, knallt hier nicht.
Nichtmal mit 1000 Mal mehr Daten.
xxx: array[1..999999999] of byte;

Also im Win32.
Mit Win64 gibt es hier noch den Bug, dass sich nichts im Debugger starten lässt. Aber das ist eine andere Sache.


PS: Da gibt es einen Delphi-Knopf im BeitragsEditor, bzw. einfach direkt [DELPHI]code[/DELPHI] drumrum.

[freimatz]

Zitat von WiWo:

Mit Delphi 12 crasht es beim Schließen, ...

"crasht" ist auch ein bischen unspezifisch ...

[himitsu]

Hast Recht.

Strg+C funktioniert in Fehlerdialogen, sowie auch in den Logs, der Delphi-IDE.
Und dann hier via Strg+V, z.B. in ein [QUOTE]der Fehlertext[/QUOTE].

[WiWo]

Erstmal Danke für die Rückmeldungen.

Sorry, "crasht" ist natürlich blöd ausgedrückt. Ich bekomme eine $C0000005-Exception "access violation at..". Wenn ich im Debugger dann stoppe, stehe ich in Vcl.Forms auf der Zeile "if not FVisualManagerInitialized then".
Zusatzinfos noch:
Win32-VCL-Anwendung
OS: Windows 11
ob das Formular ein MDI-Client ist oder nicht spielt keine Rolle. Auch nicht, ob Modal aufgerufen oder nicht.
Im übergeordneten Haupt-Formular mache ich nichts weiteres als "Form2 := TForm2.Create(Application)", wobei Form2 eine globale Variable ist.
Es gibt keinerlei Unsicherheiten bei der Reproduzierbarkeit.

[jaenicke]

Kannst du es auch in einem kleinen Beispielprojekt reproduzieren oder nur in deinem echten Projekt? Wenn du den Fehler auch in einem Beispielprojekt bekommst, könntest du das hier bitte anhängen. Wenn du es nur in deinem echten Projekt bekommst, liegt das Problem woanders. Dann ist da im Speicher wohl etwas nicht in Ordnung.

Du könntest einmal mit FastMM versuchen, ob du dort Speicherfehler angezeigt bekommst.

[himitsu]

Wenn's im Debugger knallt, dann auch den Stacktrace hier posten.

Und dann vielleicht noch sowas wie madExcept/Eurekalog/...


Wobei ich grade selbst einen schönen Fehler bei mir hab, der im Debugger nie knallt. (vermutlich irgendwas mit Threading, wo es im Debugger zeitlich langsamer nicht knallt)

[WiWo]

ich hab jetzt das Projekt sowie als Screenshot den Zustand nach der Exception rangehängt.
Bemerkt hab ich den Fehler zuerst in einem wirklich riesigen Projekt und ziemlich lange gebraucht, bis ich die Ursache gefunden hatte. Aber auch schon mit dem angehängten Winzigst-Projekt krieg ich den Fehler.
Mein Delphi-Build ist übrigens 29.0.50491.5718; ich weiß nicht, ob da grad noch kleine Updates gemacht werden.

[Kas Ob.]

Zitat von WiWo:

ich hab jetzt das Projekt sowie als Screenshot den Zustand nach der Exception rangehängt.
Bemerkt hab ich den Fehler zuerst in einem wirklich riesigen Projekt und ziemlich lange gebraucht, bis ich die Ursache gefunden hatte. Aber auch schon mit dem angehängten Winzigst-Projekt krieg ich den Fehler.
Mein Delphi-Build ist übrigens 29.0.50491.5718; ich weiß nicht, ob da grad noch kleine Updates gemacht werden.

I am out of words and at loss of straight thinking !
WTF is that stack ?
Did Embarcadero completely redesigned the TApplication in VCL ? and butchered it in the process ?

How the stack is starting at TApplication.ProcessMessage ? and where TApplication.ProcessMessages (in plural) ?
Did they handling that in a background thread ? with there most prized with anonymous procedure ?

Anyway, sorry about that rant, while i don't have newer Delphi and don't now what VisualManager is.

One quick question, (for real ):
for any empty and new VCL project, nothing added or changed except a break point on Close the main form, how the stack would look like for both x32 and x64, would someone share here with Delphi 12 ?

[peterbelow]

Zitat von Kas Ob.:

I am out of words and at loss of straight thinking !
WTF is that stack ?
Did Embarcadero completely redesigned the TApplication in VCL ? and butchered it in the process ?

In D12 they completely reworked the support for MDI UIs to allow all the modern features users expect on Win 10 and 11. There probably are a lot of legacy MDI programs around that are in dire need of updating and from Embarcadero customers with some clout ...

This Visual manager thing was appearendly introduced to implement this support, but they introduced a bug in the process as well.
At the very end of TCustomForm.WndProc there are these lines:

Delphi-Quellcode:

  inherited WndProc(Message);

  if VisualManager_AcceptMessage(Message) then
    VisualManager_WndProc(Message);
end;

Closing a secondary form with an OnClose handler that sets caFree as close action eventually calls TCustomform.Release, which posts a CM_RELEASE message to the form. The inherited WndProc call above passes that to the CMRelease message handler, which Frees the form instance. So the form self reference is invalid when VisualManager_AcceptMessage is called, and since that method tries to read a field of the form it blows up.