Root > Advanced topics > Resource leaks detection limitations

Resource leaks detection limitations

Previous pageReturn to chapter overviewNext page   

The EurekaLog resource leaks detection has some limits, which derives from its internal structure.


EurekaLog detects the resource leaks at the application's exit, so at this state the program has just freed all its non-static resources (resources allocated at run-time).


This technique generating the following limitations:

1. Enabling resource leak detection has little performance penalty (no more than about 5% for resource operations), because EurekaLog needs to build call stack for each resource allocation;
2. Enabling resource leak detection has little memory usage penalty (about 200 bytes for each resource allocation on x86-32 and about 400 bytes on x86-64);
3. Resource leak report automatically hides Assembler and CPU sections;
4. EurekaLog will not execute standard events during processing resource leak reports (this is because required resources was freed);
5. Call stack for resource leak is limited to 35 entries;
6. EurekaLog is unable to show human-readable call stack if DLL which created leak has been unloaded.
7. Resource monitoring is performed by hooking imported DLL functions.
8. Resource leaks are checked only for supported functions. Leaks in other functions will be not traced.



See also:

Send feedback... Build date: 2023-09-11
Last edited: 2023-09-04
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: