bugs in trap signal handling

[lanshun zhou]

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