[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #50557] Deadlock in signal handler

From: Aleksei Fedotov
Subject: [bug #50557] Deadlock in signal handler
Date: Thu, 16 Mar 2017 06:37:56 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0


                 Summary: Deadlock in signal handler
                 Project: make
            Submitted by: aleksei
            Submitted on: Thu 16 Mar 2017 10:37:55 AM UTC
                Severity: 3 - Normal
              Item Group: Bug
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
       Component Version: 4.2.1
        Operating System: POSIX-Based
           Fixed Release: None
           Triage Status: None




I've stumbled upon a peculiar issue, which made make to deadlock. I've
managed to reproduce it only couple of times. Make was building a
project when I send SIGINT to it. However, Make didn't exited and didn't
report any issues.

backtrace showed:

#0  __lll_lock_wait_private () at
#1  0x00007f11a03b267a in __GI___libc_malloc (bytes=139713682811680,
address@hidden) at malloc.c:2909
#2  0x00007f11a0361825 in _nl_make_l10nflist
(address@hidden <_nl_loaded_domains>,
address@hidden <_nl_default_dirname>
    dirlist_len=18, address@hidden, address@hidden
"en_US.UTF-8", address@hidden, codeset=0x0,
normalized_codeset=0x0, modifier=0x0,
    filename=0x7ffe49c9b950 "LC_MESSAGES/make.mo", do_allocate=0) at
#3  0x00007f11a035f6b7 in _nl_find_domain
<_nl_default_dirname> "/usr/share/locale", address@hidden
    address@hidden "LC_MESSAGES/make.mo",
address@hidden) at finddomain.c:91
#4  0x00007f11a035ef1c in __dcigettext (domainname=0xc62010 "make",
msgid1=0x42640c "*** Deleting file '%s'", msgid2=0x0, plural=0, n=0,
at dcigettext.c:722
#5  0x0000000000408e03 in ?? ()
#6  0x0000000000408e44 in ?? ()
#7  0x0000000000409c06 in fatal_error_signal ()
#8  <signal handler called>
#9  _int_malloc (address@hidden <main_arena>,
address@hidden) at malloc.c:3765
#10 0x00007f11a03b1850 in _int_realloc (address@hidden
address@hidden, address@hidden, address@hidden) at
#11 0x00007f11a03b2c89 in __GI___libc_realloc (oldmem=0x2088ff0, bytes=1003)
#12 0x000000000041818b in xrealloc ()
#13 0x000000000040afde in variable_buffer_output ()
#14 0x000000000040b62a in variable_expand_string ()
#15 0x000000000040b0af in expand_argument ()
#16 0x00000000004110ae in handle_function ()
#17 0x000000000040b283 in variable_expand_string ()
#18 0x000000000040bc2b in variable_expand_for_file ()
#19 0x000000000040bc93 in allocated_variable_expand_for_file ()
#20 0x000000000041593c in new_job ()
#21 0x0000000000420d9f in ?? ()
#22 0x000000000041f73e in ?? ()
#23 0x000000000041fee8 in ?? ()
#24 0x000000000041f73e in ?? ()
#25 0x000000000041fee8 in ?? ()
#26 0x00000000004210af in update_goal_chain ()
#27 0x0000000000407781 in main ()

Apparently, It seems that fatal_error_signal uses not signal safe functions,
it attempted to print message about removing intermediate target from signal
handler, and gettext implicitly allocated memory, which caused it to deadlock
with the main thread.


Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]