Call Stack page

This is "Call Stack" page in EurekaLog project's options.

Call Stack options

Options on "Call Stack" page allow you to customize EurekaLog behavior related to call stacks in bug reports.

1. "Capture stack only for exceptions from current module" (.csoCaptureOnlyModuleExceptions) option allows you to speed up execution by ignoring all exceptions outside of your executable module.

Since normal practice for exceptions is to handle them within the same module - exceptions usually do not leave module (i.e. exceptions are not shared between modules). This means that you're usually interested only in exceptions from the same module. This option allows you to ignore any other exception.

Important Note: You do not need to disable this option for packaged applications, or when you are using EurekaLog's "Lightweight DLL" profile for your DLLs. Exceptions from EurekaLog-assisted modules are shared automatically.

Note: this option is extremely useful in applications with plug-ins (including COM modules), since arbitrary exception will not be processed by each and every loaded plug-in (assuming "Capture stack only for exceptions from current module" option is enabled).

It's recommended to keep this option checked. Disable this option only when your application uses non-EurekaLog DLLs with bad API design (e.g. DLL allows exceptions to escape to the caller).

2. "Include stacks of EurekaLog-enabled threads" (.csoShowELThreads) option includes call stacks of all EurekaLog-enabled threads in application - regardless of thread type. By default only exception thread is captured.

"EurekaLog-enabled thread" term refers to thread with enabled per-thread EurekaLog. You can enable EurekaLog in any thread by calling SetEurekaLogStateInThread function or just simply create threads with TThreadEx or BeginThreadEx. See Enabling EurekaLog for background threads for more details.

Turn this option off for single-threaded application.

Turn this option on for multi-threaded application.

Note: capturing call stack of an external thread requires thread's suspending. In rare case this can cause deadlock issues (for example: thread may be suspended when it is running memory allocation function; thus, any further memory alloc/release operation will block application forever). Do not enable this option until really needed. See Using EurekaLog in multi-threaded applications for more details.

Taking call stack of additional threads will also require more time during exception processing.

Important Note: This option does NOT control if EurekaLog should automatically catch exceptions in threads. See multi-threading options.

3. "Include stacks of RTL threads" (.csoShowRTLThreads) option includes call stacks of all RTL threads in application. By default only exception thread is captured.

"RTL threads" means threads started with TThread or BeginThread.

It is recommended to keep this option off and use TThreadEx and BeginThreadEx or SetEurekaLogStateInThread together with "Include stacks of EurekaLog-enabled threads" option instead.

Turn this option on to capture call stack of external RTL threads (that is threads started by 3rd party code without your control).

Note: capturing call stack of an external thread requires thread's suspending. In rare case this can cause deadlock issues (for example: thread may be suspended when it is running memory allocation function; thus, any further memory alloc/release operation will block application forever). Do not enable this option until really needed. See Using EurekaLog in multi-threaded applications for more details.

Taking call stack of additional threads will require more time during exception processing.

Important Note: This option does NOT control if EurekaLog should automatically catch exceptions in threads. See multi-threading options.

4. "Include stacks of Windows threads" (.csoShowWindowsThreads) option includes call stacks of all non-RTL threads in application. By default only exception thread is captured.

"Windows threads" means threads started with CreateThread.

It is recommended to keep this option off and use TThreadEx and BeginThreadEx or SetEurekaLogStateInThread together with "Include stacks of EurekaLog-enabled threads" option instead. Alternatively, you may use "Include stacks of RTL threads" option instead.

Turn this option on to capture call stack of external Windows threads (that is threads started by 3rd party code without your control).

Never start your own thread with CreateThread function.

Note: capturing call stack of an external thread requires thread's suspending. In rare case this can cause deadlock issues (for example: thread may be suspended when it is running memory allocation function; thus, any further memory alloc/release operation will block application forever). Do not enable this option until really needed. See Using EurekaLog in multi-threaded applications for more details.

Taking call stack of additional threads will require more time during exception processing.

Important Note: This option does NOT control if EurekaLog should automatically catch exceptions in threads. See multi-threading options.

5. "Trace method" (.csoAllowedRenderMethods) option selects method for creating/building call stack. This option is applicable to x86-32 only, it has no effect for x86-64 platform.

The following methods are supported:

Important Notes:

5.1. "EurekaLog 7" methods are default for EurekaLog 7. This is recommended choice for new projects. This is new and improved EurekaLog stack tracing method. Improvements are done for filtering out false-positive calls. Chose these methods to get more adjusted call stack. Chose EurekaLog 6 method (see item 4.3 below) to get unfiltered call stack.

There are RAW and stack frame methods. See this explanation for differences between stack frames and RAW. RAW method includes all items from stack frames method and adds more.

5.2. "Memory debugger" methods are lightweight and fast methods which are used by memory and resource profiling features of EurekaLog. It has to be as fast as possible, so it lacks advanced checks and may introduce many inaccurate and false-positive entries.

See this explanation for differences between stack frames and RAW.

5.3. "Compatibility" methods are methods for compatibility with legacy and 3rd party code. It's not recommended to use these methods in new projects. Use these methods only for old code, which may expect certain call stack items.

Microsoft stack tracing method requires DbgHelp DLL. See: Using Microsoft's DbgHelp DLL.

madExcept stack tracing method requires madExcept installed. You will need also to include EStackTracingMadExcept unit into your project file.

6. "Delay call stack creation until handle stage" option postpones analyzing exception for later stages of processing (if possible).

Please, see this article for detailed explanation of delayed (deferred) call stacks.

Enable this option for better performance.

Disable this option for better detalization and compatibility.

Notes:

7. "Detalization level" option indicate which items should be included in call stack:

First list's item will not restrict call stack's item at all. Everything will be added. Each following list's item restricts added call stack's items. Last list's item is most restrictive: only locations with full debug information available will be added to call stack. See these articles for examples:

Recommended value is "Show items with procedure name (DLLs)" or "Show items with unit name (BPLs)".

Important Note: "Show any (including RAW addresses)" value is not recommended to be used in typical application. This value is intended to be used with dynamically generated code. Such code has no debug information available and it does not belong to any executable module, but rather it is allocated in dynamic memory (heap) or CPU stack. Use "Show any item belong to executable module (unknown locations within DLL)" instead of "Show any (including RAW addresses)" for applications that do not generate code dynamically.

Note: "Show any (including RAW addresses)" and "Show any item belong to executable module (unknown locations within DLL)" values will disable speed optimizations.

See also