Red Hat Enterprise Linux Server release 6.2 (Santiago) uname -r: 2.6.32-220.17.1.el6.x86_64 bash version: bash-4.1.2-9.el6_2.src.rpm (also tested with bash-4.2 compiled from source with patches bash42-001~bash42-037)
When interrupt_immediately is set, handler for signals registered by trap
is called
immediately after the signal is triggered. But many function calls in
trap_handler
are not async-signal-safe, so it's unsafe and could cause bash to enter
a deadlock.
For example, in read_builtin, interrupt_immediately is set, and the
following backtrace
shows how it entered a deadlock. The attachment shows how to reproduce the
problem,
and i think it's a bad idea to use interrupt_immediately in trap_handler,
even the
programming_error
(gdb) bt
#0 __lll_lock_wait_private () at
../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:97
#1 0x000000392e47bed5 in _L_lock_9323 () from /lib64/libc.so.6
#2 0x000000392e4797c6 in __libc_malloc (bytes=245592800896) at
malloc.c:3657
#3 0x0000000000465ef3 in xmalloc ()
#4 0x000000000041de9e in save_token_state ()
#5 0x0000000000450709 in run_pending_traps ()
#6 0x00000000004508fd in trap_handler ()
#7 <signal handler called>
#8 _int_malloc (av=0x392e78be80, bytes=<value optimized out>) at
malloc.c:4715
#9 0x000000392e47a846 in _int_realloc (av=0x392e78be80, oldp=0xd875f0,
oldsize=<value optimized out>,
nb=<value optimized out>) at malloc.c:5296
#10 0x000000392e47aaf5 in __libc_realloc (oldmem=0xd87600, bytes=240) at
malloc.c:3822
#11 0x0000000000465e5e in xrealloc ()
#12 0x0000000000470641 in read_builtin ()
test.sh
Description: Bourne shell script
