Status & Roadmap
Authors & License
Funding Ultimate++
Search on this site

SourceForge.net Logo

Resolving memory leaks

Before 2008.1 release, the memory leaks debugging facilities have changed. Here we try to explain why logic has changed and what problem is it supposed to solve:


Previous method involved watching for particular ADDRESS to be allocated (so that you could detemine the source of leak). Anyway, that has a problem than often the same memory block is going to be allocated more than one time - obviously, in that case the watch would only catch the first allocation, which would not be the cause of the problem.


That is why logic was improved by introducing "memory allocation serial number" - each memory allocation has associated serial number (incremental). When U++ detects a leak, it dumps all leak blocks (note that sometimes you can resolve the problem just by examining its content) to standard .log file (you can see it in theide by pressing Alt+L). And in the .log, serial number is printed for each leaked memory block. It is printed after "--memory-breakpoint__".


Now the only thing you need to do is to add "void MemoryBreakpoint(dword serial)". When Alloc for that serial happens again, __BREAK__ will segfault ("*(void *)0 = 0") the application and you will be able to catch the problem in the debugger.


Of course, the only problem with this is that the order of allocations must be exactly the same in the "test run". Which is often not, but usually it is possible to arrange it so after spending a couple of nights desperately looking for the source of leak in the code using other methods...


Last edit by cxl on 12/02/2017. Do you want to contribute?. T++