Delphi 12: Fehler mit Action := caFree

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

[Kas Ob.]

Zitat von peterbelow:

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.

Well, i disagree on expecting that behavior, my thoughts on this can be reduced to this:
1) The stack is corrupted and that is that, meaning unwind will fail to find the last SEH handler (or SEH chain) and the app will crash, in case OS catch an unhandled exception (through its own SEH) that return to specific positions, it will terminate the process, return position they are .. like if a background thread raised an exception without SEH trap, the OS will unwind and find it pointing to its origin in the kernel that called from CreateThread then the app is doomed and will be terminated then and there, also if the main thread raised an exception, and in unwinding the OS found it pointing to the code responsible for CreateProcess then also the app is done and gone, now if this is the case and it is confirmed by two users you and OP then this is reproducible RTL/VCL bug.
2) The stack is fine and the debugger is failing to walk it, then this is a debugger bug, also confirmed by 2 users.
3) Irrelevant to the stack and what the debugger is able show/walk/report, this exception confirmed by 2 users, and this is reproducible RTL/VCL bug.

So in all case this is a bug and need to be reported/fixed.

as for Vcl.Forms.TApplication.ProcessMessage being the first/oldest reported by the debugger, these is no more clearer report that there is a bug and it concern the stack itself or the debugger, like above either the debugger had failed or the stack already damaged/corrupted byt the RTL/VCL itself.
Also Vcl.Forms.TApplication.ProcessMessage is Delphi code and it is not an OS callback function, hence should and must have another code calling it from within Delphi code and that code (procedure/function) should be on the stack too, as simple as that.

[peterbelow]

Zitat von Kas Ob.:

So in all case this is a bug and need to be reported/fixed.

as for Vcl.Forms.TApplication.ProcessMessage being the first/oldest reported by the debugger, these is no more clearer report that there is a bug and it concern the stack itself or the debugger, like above either the debugger had failed or the stack already damaged/corrupted byt the RTL/VCL itself.
Also Vcl.Forms.TApplication.ProcessMessage is Delphi code and it is not an OS callback function, hence should and must have another code calling it from within Delphi code and that code (procedure/function) should be on the stack too, as simple as that.

The problem itself is a bug, no argument. But the debugger is not faulty, the stack is not corrupted. It correctly reports the location at which the exception was raised. That is just not the location that is at the root of the problem, but that is fairly often the case.

[Kas Ob.]

Zitat von peterbelow:

The problem itself is a bug, no argument. But the debugger is not faulty, the stack is not corrupted. It correctly reports the location at which the exception was raised. That is just not the location that is at the root of the problem, but that is fairly often the case.

I am sorry, may be didn't explain this clearly.

The debugger is reporting only 9 calls and stopped at TApplication.ProcessMesage , this call explicitly means there is more to it and it could be helpful or it could be not, but that is not up to the debugger to decide, it should go deeper, you already pasted two stacks report, so why one is over 50 walked and the real needed one with an exception is stopped/cut at 9 ?

That is my point about failing or buggy debugger.

Also see your first stack there is no ProcessMessages or ProcessMessage, so why that specific call in the stack (on exception) to begin with ?
If you noticed in the first stack (long) the whole process is logical and right, on other hand with the one with the exception also looks logical and fine but where and who (or whom ? bad English) did call it ?

All stacks should be resolved/walked to the origin, in the first one +50 was enough but if you want to go deeper, you should pass TApplication.Run and continue into address inside the kernel, same with threads but-there will be any TApplication.xxxx ,because they are what are they, threads.

Now back to the case at hand, Who did call ProcessMessage(MSG), and why the debugger stopped or failed to continue walking the stack from there to something declaring it is in fact the main thread form UI main message handling.

Did Application.ProcessMessages called form he main thread by design from the VCL ???? that ducked up to say the least, and that from an event triggered by the UI, well i am out of words here.
Yet again will repeat it, even if that is the case then ProcessMessage that reported in the stack should have a caller reported and resolved by the debugger.

Sorry again if that is still not clear, but i hope it might be.

[peterbelow]

Zitat von Kas Ob.:

I am sorry, may be didn't explain this clearly.

The debugger is reporting only 9 calls and stopped at TApplication.ProcessMessage , this call explicitly means there is more to it and it could be helpful or it could be not, but that is not up to the debugger to decide, it should go deeper, you already pasted two stacks report, so why one is over 50 walked and the real needed one with an exception is stopped/cut at 9 ?

You seem to have a serious misunderstanding of how the call stack works. In a VCl app practically all code in the main thread is executed in response to a posted message, so the base of the call stack is TApplication.ProcessMessage, at least all the code flow interesting for debugging starts from there. There are a few instruction below that point, which get executed during program startup. but the flow never returns to them until the program is terminated. In the case of the exception stack the path from ProcessMessages to the exception was short, so the call stack shown has few entries. In the case of the breakpoint in OnClose the path was much longer from ProcessMessages to the breakpoint.

[Kas Ob.]

Zitat von peterbelow:

You seem to have a serious misunderstanding of how the call stack works.

Well, i am half down and the other half is slow, so will not challenge that.

Zitat von peterbelow:

In a VCl app practically all code in the main thread is executed in response to a posted message, so the base of the call stack is TApplication.ProcessMessage, at least all the code flow interesting for debugging starts from there.

Can you please confirm if a button click go though TApllication.ProcessMessage ? or an event triggered like TForm.OnShow went through that ? because it doesn't,
ProcessMessage in TApllication ..
Well, as you said i am lacking understanding of stack working and VCL design, who knows may be there are, i must simply don't know.

So please forgive me for wasting your time.

[TurboMagic]

Zitat von peterbelow:

Zitat von Kas Ob.:

So in all case this is a bug and need to be reported/fixed.

Meanwhile somebody else has reported the original issue:
https://quality.embarcadero.com/browse/RSP-43547

You might want to vote for it.

[Kas Ob.]

Zitat von TurboMagic:

Meanwhile somebody else has reported the original issue:
https://quality.embarcadero.com/browse/RSP-43547

Good to hear.

Still the question, is there a bug in the debugger walking the stack ?
The bug is reliably reproducible, and that stack is reliably reproducible, this is the perfect chance to track this and solve for good.

And the question still there, could you (anyone with Delphi 12) track it and confirm the bug in the debugger, you could use Madshi or EurekaLog and compare the stack, also a breakpoint on TApplication.ProcessMessage and capture the stack at that point, another right before the exception, then after (it will break on its own), compare them and confirm if there is a failure in stack walking.

Again, i am just saying this is very lucky situation to get things fixed.

[WiWo]

ich hab inzwischen auch das Beispiel-Projekt bei RSP-43547 hochgeladen, da der ursprüngliche Poster nichts weiter hochgeladen hatte und vielleicht auch die Zusatzbedingung mit der Speichergröße des Formularobjekts nicht erkannt hat.

WiWo