Memory leak when using libbacktrace 'backtrace_full' repeatedly

[bastianbeischer]

Our application makes use of libbacktrace in order to present meaningful backtraces when certain 'errors' occur in our code. Unlike in the case of a crash report the application is allowed to continue in many cases, which can lead to repeated calls to backtrace_full().

We have observed that the memory allocated by our program increases with time and I have traced back this memory increase to the use of mmap in libbacktrace. If I understand the code correctly then the executable and its dependent libraries are mmaped into memory and parsed for DWARF debug information. But I suspect that the mmaped memory is not properly unmapped in all the cases.

I have run our code within 'valgrind --tool=massif --pages-as-heap=yes' (which means that virtual memory is measured, but I also see a similar increase in RSS) and visualized the memory consumption with massif-visualizer. I attach two figures: The memory growth as a function of time and the callgraph for the peak snapshot.

Hopefully this will help to debug the issue.

callgraph.png.gz

Thanks for your help

[ianlancetaylor]

I would guess that this is due to the fix for https://gcc.gnu.orgPR67457, in which we attempt to detect whether we can allocate memory.

[bastianbeischer]

@ianlancetaylor unfortunately the issue is not resolved with commit 012b950. If you look at the callgraph.png file (I had to gzip it because it was very large otherwise), you will see that most of the mmapped memory is actually allocated from the function backtrace_get_view (file mmapio.c) - much deeper in the stack. I suspect that there are missing backtrace_release_view calls - for example because "using_debug_view" in elf.c does not get decremented all the way to 0, so line elf.c:3104 does not munmap.

Line numbers here correspond to commit 1779403 here

[ianlancetaylor]

Thanks. I didn't understand the callgraph.png file.

Are you calling backtrace_create_state more than once while your program is executing?

[bastianbeischer]

Ouch, now I feel stupid :-)

That appears to be the problem indeed. In case I call backtrace_create_state only once and save the pointer for further use the problem disappears.

Sorry... I suppose it would be nice if the docstring of backtrace_create_state in backtrace.h would mention that it should only be called once, but in retrospect I should have figured that out myself.

That is not to say that there are no other leaks, I didn't do a thorough check, but for our usecase the problem went away.

[ianlancetaylor]

Thanks for following up.