Delphi 12: Fehler mit Action := caFree

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