When you are profiling your application with AQTime, the Event View panel displays events that occur in the profiled application and in the operating system during the profiling. You can find the list of traced events in the Event View Panel topic.
For two events - Exception and Debug String - the Event View panel shows the call stack:
- The Exception event indicates that an exception occurs in the profiled application. The call stack shows the hierarchy of function calls that led to the exception.
- The Debug String event logs a call to the Windows
OutputDebugStringfunction. The call stack of this event displays the hierarchy of function calls that led to calling that function.
The call stack is shown as child nodes of the Exception or Debug String node. The call stack nodes contain addresses and names of routines that are in the call stack.
When viewing the call stack you may come across the following problem: call stack nodes contain only routine addresses, but not routine names. This happens because AQTime cannot find names for those routines in debug information. In other words, the call stack shows the name of a routine only if AQTime can find debug information for that routine. You can fix the problem by compiling these modules with debug information. For more information on this, see How AQTime Profilers Use Metadata and Debug Information.
There are two possible problems that you may come across when viewing the call stack:
- One of the problems is that the call stack nodes contain only routine addresses, but not routine names. This happens because AQTime cannot find names for those routines in debug information. In other words, the call stack shows the name of a routine only if AQTime can find debug information for that routine. You can fix the problem by compiling these modules with debug information. For more information on this, see How AQTime Profilers Use Metadata and Debug Information.
If you are profiling a Delphi or C++Builder application, call stack nodes containing incomplete information may correspond to VCL functions and the cause of the problem is that the profiled application was compiled with the Use Debug DCUs compiler option disabled (Use debug libraries in C++Builder). The solution is simple: enable this option in the Project Options dialog and then re-build your application. For more information on how to set this option, see Compiler Settings for Borland Delphi and Compiler Settings for Borland C++Builder.
- Another problem is that the call stack may be empty. In most cases, the reason for this is simple: AQTime assumes that your application was compiled with stack frames while it was actually compiled without them or vice versa. Stack frames is a set of bytes that application routines place on the stack when they are calling their child routines. The purpose of these frames is to restore the stack to the same state as it was in before calling a routine. Since the stack frames affect the stack, they also affect the manner in which AQTime determines what routines called other routines (that is, they affect the manner in which AQTime traces the call stack).
The Event View panel includes two Rely on stack frames options (one for exceptions and the other one for debug strings) that specify the manner in which AQTime traces the call stack.
If your application was compiled with stack frames, enable the Rely on stack frames option of the Event View panel. If the application was compiled without stack frames, disable this option. If you break this rule, the call stack will be empty.
Compilers can add stack frames to your application automatically. Most modern compilers have an option that allows you to control whether the application will be compiled with stack frames or not. For more information, see Stack Frames - Compiler Settings For Native Applications and Stack Frames - Compiler Settings for .NET Applications.
Note that if the Rely on stack frames option is off, AQTime will resort to its own algorithm to determine the hierarchy of function calls. This algorithm is slower and sometimes less accurate than the one that uses stack frames. Therefore, to obtain robust results, we recommend that you compile your application with stack frames and enable the Rely on stack frames option.