Mon 16 Feb 2015 06:59:30 AM UTC, original submission:
We have integrated libunwind for all our Cisco enterprise boxes which runs on MIPS. libunwind is called at various instances: during a crash, cpuhog to generate a neat traceback on the console to isolate the root cause of the issue. We also hook libunwind to our error generating infra called from all the processes in the application and hence needed to stress test its behaviour.
We wrote a test code that creates around 20 threads and from each thread we continuously generate a traceback using libunwind.
We benchmarked libunwind mempool size and cache size and found that there is a memleak in libunwind mempool.
It can fail in fetch_proc_info and return back to the caller without freeing up the memory. This will result in pool objects being held beyond their lifetime which eventually exhausts the mempool and keeps expanding it, resulting in increasing the memory unboundedly.
The failure more specifically is in dwarf_search_unwind_table ( dwarf/Gfind_proc_info-lsb.c ) when it returns UNW_ENOINFO. This results in fetch_proc_info to return back to the caller without freeing up the allocated memory:
/* search the table: */
if (cb_data.di.format != -1)
ret = dwarf_search_unwind_table (as, ip, &cb_data.di,
pi, need_unwind_info, arg);
else
ret = -UNW_ENOINFO;
Are you aware of this issue?
I have a fix for this. Can I make this contribution?
I could reproduce this issue in X86 as well.
Thanks,
Shruti Shetty
Cisco Systems
|