<div dir="ltr">I'm trying to track down a possible memory leak in <a href="https://github.com/yinqiwen/ardb">ardb</a>, which uses jemalloc, when running on an arm processor.<div><br></div><div>The problem I have is that when I set 'MALLOC_CONF=prof_leak:true' and start ardb, the program hangs.</div><div>When I strace it, this is the system call it does:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">futex(0xb6db3c0c, FUTEX_WAIT_PRIVATE, 2, NULL</blockquote><div><br></div><div>Here's the stack trace gdb reports:</div><div>







<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">(gdb) bt <br>#0  0xb6e1af4c in __lll_lock_wait_private () from /lib/libc.so.6<br>#1  0xb6d79de4 in __new_exitfn () from /lib/libc.so.6<br>#2  0xb6d79e34 in __internal_atexit () from /lib/libc.so.6<br>#3  0x0016d75c in je_prof_boot2 () at src/prof.c:1349<br>#4  0x00143418 in malloc_init_hard () at src/jemalloc.c:767<br>#5  0x0014db70 in malloc_init () at src/jemalloc.c:292<br>#6  calloc (num=1, size=520) at src/jemalloc.c:1123<br>#7  0xb6d79da4 in __new_exitfn () from /lib/libc.so.6<br>#8  0xb6d79e34 in __internal_atexit () from /lib/libc.so.6<br>#9  0x00013410 in __static_initialization_and_destruction_0 (<br>    __initialize_p=<optimized out>, __priority=<optimized out>)<br>    at <>/include/c++/4.7.3/iostream:75<br>#10 _GLOBAL__sub_I_channel.cpp(void) () at common/channel/channel.cpp:738<br>#11 0x001786f8 in __libc_csu_init ()<br>#12 0xb6d61834 in __libc_start_main () from /lib/libc.so.6<br>#13 0x0001424c in _start ()</blockquote>















</div><div><br></div><div>I'll admit at this point I'm kind of stumped as to how to proceed. I thought I'd start by asking here in case anyone had seen similar behavior or knew what the problem was. I checked the issues at the github page and couldn't find anything similar. This is using version 3.6.0 of jemalloc.</div><div><br></div><div>When I looked at the jemalloc.xml user manual in the gate tip (not the 3.6.0 branch I'm using) I saw some discussion of atexit being problematic in the context of prof_final. If that's the problem, is there a way to generate profiling information either while the program is running, avoiding the atexit issue? I didn't quite follow the comment in the user manual that says that an application can register its own atexit parameter with equivalent functionality. Is there an example someplace I could crib from or could someone help me understand that a bit?</div><div><br></div><div>Thanks,</div><div>Brock</div><div><br></div>







</div>