Calling malloc() from within a signal handler causes permanent deadlock in Red Hat Enterprise Linux 6

Issue

• We have several processes that, when sent a SIGTERM, end up stuck with a backtrace similar to the following:

  (gdb) where
  #0  0x00007f3ee2b60dce in _lll_lock_wait_private () from /lib64/libc.so.6
  #1  0x00007f3ee2aec138 in _L_lock_9164 () from /lib64/libc.so.6
  #2  0x00007f3ee2ae9a32 in malloc () from /lib64/libc.so.6
  #3  0x00007f3ee1f691ad in ?? () from /apps/prman/RenderManProServer-15.2p11/bin/../lib/libprman.so
  #4  0x00007f3ee18546a1 in ?? () from /apps/prman/RenderManProServer-15.2p11/bin/../lib/libprman.so
  #5  <signal handler called>
  #6  0x00007f3ee2ae5795 in malloc_consolidate () from /lib64/libc.so.6
  #7  0x00007f3ee2ae8612 in _int_malloc () from /lib64/libc.so.6
  #8  0x00007f3ee2ae9a3d in malloc () from /lib64/libc.so.6
  #9  0x00007f3ee0abecef in inflateInit2 () from /lib64/libz.so.1
  #10 0x00007f3ee22fe277 in ?? () from /apps/prman/RenderManProServer-15.2p11/bin/../lib/libprman.s

• The issue is reproducible by calling a SIGTERM signal handler while the application is within the call to malloc(), and then calling malloc() from within the signal handler itself.