In 2010-2011, mmlr created a new memory allocator: the guarded heap memory allocator. This allocator helps detect various bugs such as writing past the end of allocated memory, reading uninitialized memory, and freeing freed memory. These uses are detailed in “Using malloc_debug to Find Memory Related Bugs”. Later, in 2015, mmlr had a new project: updating the memory allocator to be able to report memory leaks.
It seems a little intimidating, is there a way to combine all these steps into one (sophisticated?) script ?, is there anyone working on the gdb port?, that would a be an easier debugger to include in such automated environment, right?
The garbled function names are usually referred to as “mangled”. They are compressed to take less space in the executable. To get the readable name back one would “demangle” it.
It is also one of the reason you use extern “C” around functions, as it reports the function names the way C expects to find them.
I think Haiku has functions to demangle names, so probably the report could be demangled before printing. Perhaps this takes to much CPU though, and therefore done by the script.
There was some discusssion around this in https://github.com/haiku/website/pull/632. The leak_analyser.sh script could be modified to do this. One method would be to use nm to find the function’s address, add the offset to it using bc, then use llvm-addr2line (addr2line does not work for some reason) to turn this address into a line in source code.
Yes, I believe the memory is freed on program exit. Trouble could arise if it is a long-running program that slowly takes up more and more memory without ever freeing it.