I'm trying to figure out why my large project does not report memory leaks (C++ Builder Sydney R1; madCollection 2.8.9.1; VCL application (converted from earlier C++ Builder version); legacy compiler; mostly statically linked; dynamic RTL; > 800 units, the resulting exe is 42 Mb, the tds file is 213 Mb). Things I have checked:
In the madExcept settings leak reporting is on.
madExcept is linked into the application (madBasic_.lib, madDisAsm_.lib, madExcept_.lib).
madExcept32.dll is present in the folder where the exe is. (note: DLL file properties report version 4.0.6.0, which is the same as my earlier version of madExcept. But the file size is 970.560 bytes, which differs from my earlier version of madExcept)
No message "Well done = No leaks found" either.
When I manually call Madexcept::StartLeakChecking soon after the start of the application, it does report leaks when the application exits. But I'd rather have leak checking started immediately when starting the application.
A small sample application compiled in the same IDE *does* report leaks.
Do you have any suggestion as where to look for the reason no leaks are reported? E.g. includes/links to check, any (debug) output/logging created during compile I could check? I've had a look at the contents of madExceptWizard.txt, but I'm not sure what to look for.
You can check out the RCDATA\MADEXCEPT resource in your compiled EXE file, using the freeware "Resource Hacker". Does it say "ReportLeaks = False" or "ReportLeaks = True"?
That's really weird. The only thing coming to my mind would be for you to add madExcept.pas and mad.inc into your project, so they're actually compiled into your EXE file, instead of using the precompiled DCU/OBJ files that shipping with madExcept. This way you can actually set breakpoints in madExcept.pas to check what's going on.
Thanks to your suggestions I've found the issue in my code. After compiling madExcept.pas into my application, I now got an access violation at the startup of my application, which pointed me to a problem in my code. By some coincidence this issue manifested itself before not with an access violation, but by interfering with the proper working of leak checking in madExcept. After fixing this problem and removing madExcept.pas from my project again, madExcept reports leaks as expected.