[Q] Strange hang in jemalloc

[Mitchell Blank Jr]

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