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.
This is a companion discussion topic for the original entry at https://www.haiku-os.org/blog/zardshard/2023-05-23_how_to_find_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.
what khallebal said, or something like valgrind to make it easier
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
addr2line does not work for some reason) to turn this address into a line in source code.
On gcc3+ there is the builtin
__cxa_demangle to do this FWIW, no special Haiku support needed.
Is it very bad to have non-freed memory when the program exits? The heap/pages will be released at that time anyway, isn’t it?
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.
If c++filt is available/ported, I find that quite useful for de-mangling:
(devbox) c++filt -n _ZN8BPrivate10TFilePanelC2E15file_panel_modeP10BMessengerPK6BEntryjbP8BMessageP10BRefFilterj11window_look11window_feelb
BPrivate::TFilePanel::TFilePanel(file_panel_mode, BMessenger*, BEntry const*, unsigned int, bool, BMessage*, BRefFilter*, unsigned int, window_look, window_feel, bool)