Taehwan Weon wrote:
#6 0x00002b59a803f555 in jemalloc_prefork () at src/jemalloc.c:1760 #7 0x000000351ca9a2a6 in fork () from /lib64/libc.so.6 #8 0x000000351ca6200d in _IO_proc_open@@GLIBC_2.2.5 () from /lib64/libc.so.6 #9 0x000000351ca62269 in popen@@GLIBC_2.2.5 () from /lib64/libc.so.6 #10 0x00002b59a71bc1f9 in backtrace_lineinfo (number=1, address=<value optimized out>, symbol=0x2b61f4000918 "/usr/lib64/libnc.so.2 [0x2b59a71bc3b1]") at cfs_apix.c:363 #11 0x00002b59a71bc3ff in nc_dump_stack (sig=<value optimized out>) at cfs_apix.c:423 #12 <signal handler called>
Just a side note: popen() is not an async-signal safe function, so you should not expect that to work from inside a signal handler. Neither is malloc(). I'd be even more careful about something from a SIGSEGV/SIGBUS handler since the heap might be damaged.
I believe, however, that fork() is supposed to be signal-safe (at least according to "man 7 signal") so there might be a jemalloc issue in this deadlock as well. However it looks like it can only happen if the fork() is being called from a SEGV handler that happened inside jemalloc itself, which is a bit of an edge case.
-Mitch _______________________________________________ jemalloc-discuss mailing list [email protected] http://www.canonware.com/mailman/listinfo/jemalloc-discuss
