事件处理期间的Delphi堆栈信息

Question

When debugging events I would like to see the "complete" stack, specifically the actual event or method that triggered an event.

A simple example would be to drop a ComboBox on a form, and write an onChange event. The onChange event will trigger when a user changes the comboBox (obviously), but it can also get triggered via other routines, eg, at startup, the formActivate will trigger it.

If I place a breakpoint in the OnChange event of the comboBox, I won't see the triggering stack. Why is this, and how can I get this "other" stack info during debugging?

I know I can step through the event and it will eventually bring me back to the triggering code, this is not what I am looking for.

Thank you!

---

I thought I would post an image of how enabling dcu's worked. Note that the FormCreate event actually appears in the stack now.

Here is an image of two different stack traces. Breakpoint is exactly the same in both, note that after enabling debug dcu's in the second, I get stack information from my code (not just vcl/rtl).

Answer 1

I suspect that you are missing the RTL/VCL functions from the stack trace. To make them show up, enabled Debug DCUs in the project options.

Answer 2

After enabling Debug DCU's, I saw my own code in the stack. Specifically the FormCreate handler only appeared after enabling debug dcus. I was surprised by this.

See this :

Stack frames for frame-based methods

RTL and VCL units are compiled with "Stack Frames" option turned off. This means that any frame-based method will not be able to find short routines in RTL/VCL units.

However, this fact also have less obvious consequence. Consider this code:

procedure TForm1.Button1Click(Sender: TObject);
begin
  TStringList.Create;
end;

This code creates a simple memory leak by leaking instance of TStringList. A tracing tool will detect a leak and build call stack for it. Button1Click routine has stack frame due to "Stack Frames" option being enabled for your project. One may expect that frame-based tracing method will discover a call to Button1Click and add it to the call stack.

This is not so.

The stack frame for Button1Click allows method to identify the caller (in this case: TControl.Click). That's because stack frame does not contain information about routine itself . It contains information about the caller : return address . Return address for Button1Click routine will point to TControl.Click.

But what about Button1Click? Since TStringList is a class from RTL - it's compiled without "Stack Frames" option. Thus, constructor does not have stack frame (because it's very simple code and do not require stack frame). Therefore, it's not possible for frame-based tracing method to identify Button1Click routine.