Delphi 12: Fehler mit Action := caFree

[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.

[Kas Ob.]

Zitat von 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.

Thank you for the details, i really appreciate it, still one thing you did not confirm yet, and will be really insightful.
On you Delphi is the stack cut at TApllicatiom.ProcessMessage too ? like WiWo screenshot, that is a problem not smaller the broken design !

[peterbelow]

Zitat von Kas Ob.:

Thank you for the details, i really appreciate it, still one thing you did not confirm yet, and will be really insightful.
On you Delphi is the stack cut at TApllicatiom.ProcessMessage too ? like WiWo screenshot, that is a problem not smaller the broken design !

If I run to a breakpoint in the OnClose handler the full call stack looks like this

Unit2.TForm2.FormClose($7F650010,caHide)
Vcl.Forms.TCustomForm.DoClose(???)
Vcl.Forms.TCustomForm.Close
Unit2.TForm2.Button1Click($3157C10)
Vcl.Controls.TControl.Click
Vcl.StdCtrls.TCustomButton.Click
Vcl.StdCtrls.TCustomButton.CNCommand(???)
Vcl.Controls.TControl.WndProc((48401, 1634, 591458, 0, 1634, 0, (), 1634, 9, (), 0, 0, ()))
Vcl.Controls.TWinControl.WndProc((48401, 1634, 591458, 0, 1634, 0, (), 1634, 9, (), 0, 0, ()))
Vcl.StdCtrls.TButtonControl.WndProc((48401, 1634, 591458, 0, 1634, 0, (), 1634, 9, (), 0, 0, ()))
Vcl.Controls.TControl.Perform(???,???,591458)
Vcl.Controls.DoControlMsg(???,(no value))
Vcl.Controls.TWinControl.WMCommand((273, (), 1634, 0, (), 591458, 0))
Vcl.Forms.TCustomForm.WMCommand((273, (), 1634, 0, (), 591458, 0))
Vcl.Controls.TControl.WndProc((273, 1634, 591458, 0, 1634, 0, (), 1634, 9, (), 0, 0, ()))
Vcl.Controls.TWinControl.WndProc((273, 1634, 591458, 0, 1634, 0, (), 1634, 9, (), 0, 0, ()))
Vcl.Forms.TCustomForm.WndProc((273, 1634, 591458, 0, 1634, 0, (), 1634, 9, (), 0, 0, ()))
Vcl.Controls.TWinControl.MainWndProc(???)
System.Classes.StdWndProc(657428,273,1634,591458)
:75d40eab USER32.AddClipboardFormatListener + 0x4b
:75d37e5a ; C:\WINDOWS\SysWOW64\USER32.dll
:75d37239 ; C:\WINDOWS\SysWOW64\USER32.dll
:75d3587f USER32.SendMessageW + 0x6f
:6e0c6618 ; C:\WINDOWS\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.19041.3636_none_a863 d714867441db\comctl32.dll
:6e105f33 ; C:\WINDOWS\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.19041.3636_none_a863 d714867441db\comctl32.dll
:75d40eab USER32.AddClipboardFormatListener + 0x4b
:75d37e5a ; C:\WINDOWS\SysWOW64\USER32.dll
:75d37537 ; C:\WINDOWS\SysWOW64\USER32.dll
:75d356db USER32.CallWindowProcW + 0x1b
Vcl.Controls.TWinControl.DefaultHandler(???)
:005ff9e2 TWinControl.DefaultHandler + $136
:005ff88c TWinControl.WndProc + $6AC
:00614f89 TButtonControl.WndProc + $71
:00588db2 StdWndProc + $16
:75d40eab USER32.AddClipboardFormatListener + 0x4b
:75d37e5a ; C:\WINDOWS\SysWOW64\USER32.dll
:75d35bca ; C:\WINDOWS\SysWOW64\USER32.dll
:75d35990 USER32.DispatchMessageW + 0x10

[Kas Ob.]

Zitat von peterbelow:

If I run to a breakpoint in the OnClose handler the full call stack looks like this

Unit2.TForm2.FormClose($7F650010,caHide)
Vcl.Forms.TCustomForm.DoClose(???)

Well, that is normal, and there is no ProcessMessage there, the stack when the exception raised is the most critical to find/capture, hence my question about why it is cut in the screenshot, or just the debugger is failing to walk the stack which indicate bigger/deeper issue in RTL/VCL flow like stack overflow (overwrite, wrong declaration..) or just a reproducible debugger failure.

[peterbelow]

Zitat von Kas Ob.:

Well, that is normal, and there is no ProcessMessage there, the stack when the exception raised is the most critical to find/capture, hence my question about why it is cut in the screenshot, or just the debugger is failing to walk the stack which indicate bigger/deeper issue in RTL/VCL flow like stack overflow (overwrite, wrong declaration..) or just a reproducible debugger failure.

If I let the IDE break on the exception the call stack does look like in original post:

Vcl.Forms.TCustomForm.VisualManager_AcceptMessage( (45089, 0, 0, 0, 0, 0, (), 0, 0, (), 0, 0, ()))
Vcl.Forms.TCustomForm.WndProc((9960336, 9960352, 9960168, 9960168, 64416, 151, (), 64232, 151, (), 64232, 151, ()))
Vcl.Controls.TWinControl.MainWndProc(???)
System.Classes.StdWndProc(721212,45089,0,0)
:75d40eab USER32.AddClipboardFormatListener + 0x4b
:75d37e5a ; C:\WINDOWS\SysWOW64\USER32.dll
:75d35bca ; C:\WINDOWS\SysWOW64\USER32.dll
:75d35990 USER32.DispatchMessageW + 0x10
Vcl.Forms.TApplication.ProcessMessage(???)

That is what I would expect in this situation since the code flow after the PostMessage for the cm_release message returns to the main message loop in TApplication.Run, and thus the call stack unwinds to that location. There is no way to determine where in the code the message was posted, so the debugger cannot show that. Of course that is unfortunate in this case since the stack does not reveal the actual cause of the problem, but we have to live with it since that's how Windows apps work. The debugger can do nothing for us here, the info it would need is simply not there.

[TurboMagic]

Zitat von peterbelow:

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.

Thanks for this thorough analysis!
Did you already check if that bug is already known? Means a QP report for it exists?
If none exists yet, would you be so kind to file one?

Ok, I just saw your last post in german on tis matter where you ask the OP to create a QP report if none exists yet.
So please disregard this one. The OP should use your material though, as this looks like a quite good starting point
for fixing it.

[peterbelow]

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.

Ich kann das Problem in D12 reproduzieren, nur die Fehleradressen sind nicht immer gleich. Das ist ein echter Bug, der beim Implementieren des verbesserten MDI-Supports in TCustomForm.WndProc eingebaut wurde, siehe Post #9 in diesem Thread.

Bitte sei so nett und lege einen Bugreport mit deinem Beispielprogramm auf quality.embarcadero.com an.