Emacs hangs occasionally due to malloc calls in signal handler

Bug #291871 reported by Martin Stjernholm
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
emacs21 (Ubuntu)
New
Undecided
Unassigned

Bug Description

Binary package hint: emacs21

I have experienced occasional hangs in Emacs for some time now. This has prompted me to compile Emacs with debug symbols to be able to track it down, and just now I managed to capture a hang shortly after startup in gdb. The backtrace shows a deadlock in a malloc mutex due to mallopt() being called from a signal handler that has interrupted an earlier mallopt() call:

(gdb) bt
#0 0x00007fcb51e1c24e in __lll_lock_wait_private () from /lib/libc.so.6
#1 0x00007fcb51db0500 in _L_lock_3213 () from /lib/libc.so.6
#2 0x00007fcb51daadd5 in mallopt () from /lib/libc.so.6
#3 0x00000000005579ab in emacs_blocked_malloc (size=36)
    at /usr/local/debs/hardy-local/emacs21-21.4a+1/src/alloc.c:732
#4 0x00007fcb517245a9 in ?? () from /usr/lib/libxcb.so.1
#5 0x00007fcb51724aa7 in xcb_poll_for_event () from /usr/lib/libxcb.so.1
#6 0x00007fcb5231cd75 in ?? () from /usr/lib/libX11.so.6
#7 0x00007fcb5231d426 in _XEventsQueued () from /usr/lib/libX11.so.6
#8 0x00007fcb52306fcd in XPending () from /usr/lib/libX11.so.6
#9 0x00000000004b5bbf in XTread_socket (sd=1376344544, bufp=0x7fff5c4158a0,
    numchars=4096, expected=1)
    at /usr/local/debs/hardy-local/emacs21-21.4a+1/src/xterm.c:9960
#10 0x00000000004f10ca in read_avail_input (expected=1)
    at /usr/local/debs/hardy-local/emacs21-21.4a+1/src/keyboard.c:6169
#11 0x00000000004f13ee in input_available_signal (signo=29)
    at /usr/local/debs/hardy-local/emacs21-21.4a+1/src/keyboard.c:6327
#12 <signal handler called>
#13 0x00007fcb51daa2b6 in malloc_consolidate () from /lib/libc.so.6
#14 0x00007fcb51daade1 in mallopt () from /lib/libc.so.6
#15 0x000000000055962e in allocate_vectorlike (len=5, type=MEM_TYPE_VECTOR)
    at /usr/local/debs/hardy-local/emacs21-21.4a+1/src/alloc.c:2234
#16 0x00000000005596f1 in allocate_vector (nslots=5)
    at /usr/local/debs/hardy-local/emacs21-21.4a+1/src/alloc.c:2254

I have verified that __lll_lock_wait_private never returns.

Judging from the libc documentation regarding Signal Handling and Nonreentrant Functions (24.4.6), I believe the bug is that Emacs does rather too much work from within a signal handler.

I'm using hardy and emacs21 21.4a+1-5.3ubuntu1.1. The complete gdb backtrace is attached.

Revision history for this message
Martin Stjernholm (msub) wrote :
Revision history for this message
Martin Stjernholm (msub) wrote :

The problem is that the signal handler isn't blocked in the mallopt() calls. The attached patch fixes it. The patch is based on the fix made in emacs 22, and I've also looked through the sources for mallopt() calls and DOUG_LEA_MALLOC code to ensure all instances are fixed.

Revision history for this message
Sylvain Nahas (myself-sylvain-nahas) wrote :

Hi,
I experience very regular hangs of emacs-gtk. The window freezes for around 10 seconds, and sometimes when it happens, the whole GNOME desktop freezes as well. There is no visible triggers to that except interacting with the GUI.

This is very inconvenient since emacs is the only available IDE for a lot of interesting projects, including Isabelle and Agda.
It renders the whole program unusable.

Ubuntu version: Ubuntu 9.10 (freshly updated)
emacs version: GNU Emacs 22.2.1 (i486-pc-linux-gnu, GTK+ Version 2.18.3) of 2010-03-26 on rothera, modified by Ubuntu.

Sylvain

Revision history for this message
Martin Stjernholm (msub) wrote :

That problem is unrelated to this bug. This one is characterized by:

o Emacs 21 only.
o Emacs hangs indefinitely.
o It's a deadlock (no cpu consumption during hang).
o Does not affect other processes.

Revision history for this message
Glen Fullmer (gfullmer-yahoo) wrote :

I have the same emacs only locking problem. One workaround that I found interesting is to execute a menu function and then the cursor returns.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.