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

Solution Verified - Updated -


  • 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/
    #1  0x00007f3ee2aec138 in _L_lock_9164 () from /lib64/
    #2  0x00007f3ee2ae9a32 in malloc () from /lib64/
    #3  0x00007f3ee1f691ad in ?? () from /apps/prman/RenderManProServer-15.2p11/bin/../lib/
    #4  0x00007f3ee18546a1 in ?? () from /apps/prman/RenderManProServer-15.2p11/bin/../lib/
    #5  <signal handler called>
    #6  0x00007f3ee2ae5795 in malloc_consolidate () from /lib64/
    #7  0x00007f3ee2ae8612 in _int_malloc () from /lib64/
    #8  0x00007f3ee2ae9a3d in malloc () from /lib64/
    #9  0x00007f3ee0abecef in inflateInit2
    () from /lib64/
    #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.


  • Red Hat Enterprise Linux

Subscriber exclusive content

A Red Hat subscription provides unlimited access to our knowledgebase, tools, and much more.

Current Customers and Partners

Log in for full access

Log In

New to Red Hat?

Learn more about Red Hat subscriptions

Using a Red Hat product through a public cloud?

How to access this content