If the Objects category is selected in the Explorer panel, the Report panel displays results for objects and detected memory block violations. This panel contains three panes: Creation Call Stack, References From and References To. The following sections describe the information that is displayed in these panes:
Creation Call Stack Pane| Note: | The profiler detects violations of memory block bounds when the block is deleted or reallocated, when the application terminates or when the Get Results command is executed. For a detailed description of how the profiler displays the call stack, refer to the Checking Bounds of Memory Blocks topic. |
Creation Call Stack Pane
If you select a Report panel row that corresponds to an object, the Allocation profiler displays information about object references in the Details panel.
| Note: | The stack is available if any of the stack areas specified in the Collect Stack Information Pane is selected. To disable the stack tracing, clear all the check boxes shown in this pane. |
The contents of the Creation Call Stack pane depend on the type of the row selected in the Report panel:
-
If the row corresponds to an object, then the page displays the stack of function calls that led to the object creation. The topmost routine in this stack is the one that created the object. Columns of the Creation Call Stack page contain information that helps you locate the routine in source code.
When profiling an application at line level, you can view the source code of a routine. To do this, simply double-click it in the call stack - AQTime will bring up the Editor panel and position the cursor on the routine’s code in it. However, in order for AQTime to get the source code, the following requirements should be met:
-
You need to compile the application with debug information. See How AQTime Profilers Use Metadata and Debug Information.
-
The source file of the routine must be specified in the Project Search Directories dialog.
-
-
If the row corresponds to the Memory Overwrite Error, then the call stack shows the sequence of function calls that led to the error detection. Errors with the memory block bounds are found only when the corresponding memory block is released or reallocated, when the application terminates or when the Get Results command is executed.
The contents of the call stack depend on the situation when the error was detected. If the error was detected when a corrupted block was deleted or reallocated, the call stack for the Memory Overwrite Error will contain function calls that led to the error detection, not to the error occurrence. If the error was detected when the application terminates or when the Get Results command is executed, the call stack will be empty. See Checking Bounds of Memory Blocks.
This information is shown in the grid that has the following columns:
| Columns (in alphabetical order) | Description |
|---|---|
| Class Name | Name of the object class containing the routine. |
| Module Name | Name of the module containing the routine. |
| Routine Name | Name of the routine. |
| Source File | Name of the source file for the routine. The values for this column are read from the application’s debug info. If debug info does not contain information on the file name, the column is empty. |
| Source Line | If the stack information is collected by routines during the profiling (that is, if the Routines only option corresponding to the desired stack area is selected), the column specifies the number of the source code line where the routine’s implementation begins.
If the Collect info about lines option that corresponds to the desired stack area is selected, the column specifies the number of the source code line where the method that creates or deletes an object reference was called. The values for this column are read from the application’s debug info. If the debug info does not contain information on the file name, the column is empty. |
| Unit Name | The name of the unit that stores the routine’s code. |
Note that sometimes the call stack may not display some information for Visual C++, Delphi or C++Builder modules. For instance, there may be no information about source files. This happens because AQTime cannot find this information in debug info. To get a more detailed call stack, you may need to recompile your application or add certain dynamic link libraries to the Setup panel. For more information on this, see Allocation Profiler - Analyzing Visual C++ Applications, Allocation Profiler - Analyzing Delphi Applications and Allocation Profiler - Analyzing C++Builder Applications.
| Note: | If the call stack is empty, most likely, you have not added any elements to the Collect Stack Information pane or you have not selected any stack area in this pane. For more information, see Specifying Modules to Be Included Into the Call Stack.
Another possible reason is the absence of debug information for profiled modules that have been added to the Collect Stack Information pane. For more information, see How AQTime Profilers Use Metadata and Debug Information. |
References To and References From Panes
The References From pane lists all objects that refer to the currently selected object. The References To pane shows objects, to which the selected object refers.
 |
The Allocation profiler traces references to managed objects only. If you select an unmanaged object in the Report panel, the References To and References From pages of the Details panel will display only the selected object, without any links to other objects. |
Information about object references is shown in grids containing the following columns:
| Columns (in alphabetical order) | Description |
|---|---|
| # | The creation number of the object. |
| Address | Object's address in memory. |
| Class Name | The name of the object’s class. |
| Count | The number of references to/from the object (for instance, if object A that is displayed in the Report panel contains two references to object B, the Count column of the References To table will display 2 for object B). |
| Object Name | The object name. It is formed as Class Name + period + number. For example, TestClass.3 means the third TestClass object that was created after the profiling started. |
| Root | If Root is checked, the object is referred to by an existing global or local variable or by a function parameter. If Root is unchecked, the object is referred to by a property of another object’s field. |
| Size | The object’s size in bytes. |
| Thread | Specifies the thread where the object’s constructor was called. |
See Also
Allocation Profiler - Results of the Objects Category
Allocation Profiler - Overview
Allocation Profiler Panels Reference
Details Panel