Root > Integral parts > Options > Features page > Resource leaks page

Resource leaks page

Previous pageReturn to chapter overviewNext page   

This is "Resource leaks" page in EurekaLog project's options.



Resource leaks detection options


EurekaLog is capable to track resource leaks - dynamically allocated resources other than memory.


1. "Catch resource leaks" option enables resource leaks checking. Resource leak is a handle of some object which wasn't released. Usually it's a bug in your application.


If this option is unchecked - there will be no additional checks performed. If this option is checked and your application doesn't have any resource leak bugs - there will be no difference in application's behaviour. If this option is checked and your application has leaked the resource - there will be a usual EurekaLog's error message on application's shutdown. This error message will use dialog and send option as set in EurekaLog's options.



Resource leak detection have some limitations.
Resource leaks detection works only with supported functions.



2. "Active only when running under debugger" option alters activation behaviour of "Catch resource leaks" option.


If this option is checked - resource leak detection will only be activated when running application under debugger (like IDE). This can be useful if you want to debug your applications on developer's machine, but do not want to annoy end-users with useless error reports (because in most cases resource leaks don't bother end-users).


Note: it's recommended to always keep this option on, unless you're creating a server or service application.



3. "Allow manual activation control" option alters activation behaviour of "Catch resource leaks" option. If this option is checked - resource leak detection can be manually turned on or off via command-line switches.


Use "/EL_EnableResourceLeaks" to enable resource leak detection.

Use "/EL_DisableResourceLeaks" to disable resource leak detection.


If this option is unchecked - these command-line switches are ignored. If this option is checked - these command-line switches will turn on or off resource leaks detection. Command-line switches will override any other check for resource leak detection activation.


This option can be used with "Active only when running under debugger" option.


This option is useful, when you want to temporary enable resource leaks detection - for example, you can activate "Active only when running under debugger" option and deploy your application to end customers without bothering them with leaks error report. However, if some customer will report problems with memory/resource usage - you can always advise to use command-line switch to enable resource leaks detection.


Note: it's recommended to always keep this option on.



4. "RAW stack tracing" option switches EurekaLog to use RAW tracing method for building call stacks for resource leaks. By default EurekaLog uses frame-based tracing method.


RAW stack tracing can show more complete call stacks, but it's significantly slower. See also: RAW method and frame-based method.


Turn on for best detalization.

Turn off for best performance.


Note: it's recommended keep this option unchecked, until you face problem which you can't solve without more detailed call stack.


Warning: do not ship your product to clients with "RAW stack tracing" option enabled. Performance of your application will be significantly lower.



5. "Hide RTL/VCL leaks" option hides known RTL/VCL leaks. There are some leaks which are "by design" or are bugs in old Delphi/C++ Builder versions. You can't fix them, but you can ignore them.


Turn on to hide expected leaks or leaks from RTL/VCL bugs.

Turn off for better detalization.


Note: if you found another "known bug" of Delphi/C++ Builder - please, send us a description and demo, so we'll be able to exclude this leak from reporting and improve our "Hide RTL/VCL leaks" option.



See also:

Send feedback... Build date: 2022-03-28
Last edited: 2018-06-14
The documentation team uses the feedback submitted to improve the EurekaLog documentation. We do not use your e-mail address for any other purpose. We will remove your e-mail address from our system after the issue you are reporting has been resolved. While we are working to resolve this issue, we may send you an e-mail message to request more information about your feedback. After the issues have been addressed, we may send you an email message to let you know that your feedback has been addressed.

Permanent link to this article: