bugs in trap signal handling
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 0x00392e47bed5 in _L_lock_9323 () from /lib64/libc.so.6
#2 0x00392e4797c6 in __libc_malloc (bytes=245592800896) at
malloc.c:3657
#3 0x00465ef3 in xmalloc ()
#4 0x0041de9e in save_token_state ()
#5 0x00450709 in run_pending_traps ()
#6 0x004508fd in trap_handler ()
#7
#8 _int_malloc (av=0x392e78be80, bytes=) at
malloc.c:4715
#9 0x00392e47a846 in _int_realloc (av=0x392e78be80, oldp=0xd875f0,
oldsize=,
nb=) at malloc.c:5296
#10 0x00392e47aaf5 in __libc_realloc (oldmem=0xd87600, bytes=240) at
malloc.c:3822
#11 0x00465e5e in xrealloc ()
#12 0x00470641 in read_builtin ()
test.sh:
#!/bin/bash
SIG=USR1
tmpfile=`mktemp`
echo
"fajksdjflasjdfljasdlfjsladjflsajdff
afadsfksdasfasdlfjasldfjlasjdflsajdlfjsdlfkjsldkjflsdjflajsdlfkjsdlfjsldkjflsdjf
fadffaljfdljasdlfjlasdkjflksadjflasjdlfjdlsfffaaadf"
> $tmpfile
testfunc ()
{
trap "echo -n '?';" "SIG$SIG"
while true; do
while read line; do
echo -n .
done < $tmpfile
usleep 100
done
}
testfunc &
bgpid=$!
echo "test pid: $bgpid"
trap "kill $bgpid; rm -f $tmpfile; exit;" SIGINT
usleep 1
while true; do
kill -"$SIG" $bgpid 2>/dev/null || exit 1
usleep 1
done
test.sh
Description: Bourne shell script
bugs in trap signal handling
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 0x00392e47bed5 in _L_lock_9323 () from /lib64/libc.so.6 #2 0x00392e4797c6 in __libc_malloc (bytes=245592800896) at malloc.c:3657 #3 0x00465ef3 in xmalloc () #4 0x0041de9e in save_token_state () #5 0x00450709 in run_pending_traps () #6 0x004508fd in trap_handler () #7 #8 _int_malloc (av=0x392e78be80, bytes=) at malloc.c:4715 #9 0x00392e47a846 in _int_realloc (av=0x392e78be80, oldp=0xd875f0, oldsize=, nb=) at malloc.c:5296 #10 0x00392e47aaf5 in __libc_realloc (oldmem=0xd87600, bytes=240) at malloc.c:3822 #11 0x00465e5e in xrealloc () #12 0x00470641 in read_builtin () test.sh Description: Bourne shell script
Re: bugs in trap signal handling
On 10/10/12 2:53 AM, lanshun zhou wrote: > 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. Thanks for the report. This has been under discussion for a long time. There are a couple of issues: how one satisfies users' expections of responsiveness, and what to do with partially-read input. The work on that continues. Right now, I've been running a slightly modified version of your script (I changed the echo -n ? to echo ? to avoid stdio buffering issues) for over an hour on a RHEL5 system without any lockups. I have ideas about what to do to reduce the potential deadlock window, but I need a way to measure the effect of those changes. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: different exit codes in $? and ${PIPESTATUS[@]}
Wladimir Sidorenko writes:
> Dear all,
>
> After running the following command:
>
> $ ! test 0 -eq 0
>
> I can see different exit codes in $? and ${PIPESTATUS[@]}. Here, what I get
>
> $ ! test 1 -eq 0 ; echo $? ${PIPESTATUS[@]}
> 0 1
>
> $ ! test 0 -eq 0 ; echo $? ${PIPESTATUS[@]}
> 1 0
>
> I'd like to know whether that's a desired behavior or a bug.
PIPESTATUS records the exit status of each command of a pipeline. !
operates on the whole pipeline, not on the invidual commands.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
