Re: deadlock in waitchld()
I have done a bit of debugging and have some results: The problem is that waitchld is called even if there aren't any children running. The waitchld() is called more then once. I don't know what is the logic behind it. Will check, if there is any child, helps? RR On 05/20/2013 04:11 PM, Roman Rakus wrote: Bash hangs in wait4() (WAITPID) if TERM signal trap handler is executed during execution of pipeline. RR Reproducer: #!/bin/bash trap "/bin/echo trapped $$" TERM printf '%d\n' $$ while :; do dd if=/dev/zero bs=1k count=128 2>&1 | cat > /dev/null done and bombard the bash process with TERM signals: #!/bin/bash while :; do kill -TERM $1 || break usleep 10 done
Re: deadlock in waitchld()
The race is in do-while loop in wait_for(). At the start of wait_for() we are blocking SIGCHLD, however echo process ends during the loop and we don't register it (don't handle SIGCHLD, which is sent). Looking at the code, there is MUST_UNBLOCK_CHLD. May it make any harm to enable it by default? RR On 05/24/2013 02:12 PM, Roman Rakus wrote: I have done a bit of debugging and have some results: The problem is that waitchld is called even if there aren't any children running. The waitchld() is called more then once. I don't know what is the logic behind it. Will check, if there is any child, helps? RR On 05/20/2013 04:11 PM, Roman Rakus wrote: Bash hangs in wait4() (WAITPID) if TERM signal trap handler is executed during execution of pipeline. RR Reproducer: #!/bin/bash trap "/bin/echo trapped $$" TERM printf '%d\n' $$ while :; do dd if=/dev/zero bs=1k count=128 2>&1 | cat > /dev/null done and bombard the bash process with TERM signals: #!/bin/bash while :; do kill -TERM $1 || break usleep 10 done
Re: deadlock in waitchld()
On 5/24/13 9:30 AM, Roman Rakus wrote: > The race is in do-while loop in wait_for(). At the start of wait_for() we > are blocking SIGCHLD, however echo process ends during the loop and we > don't register it (don't handle SIGCHLD, which is sent). > Looking at the code, there is MUST_UNBLOCK_CHLD. May it make any harm to > enable it by default? I spent a lot of time looking at this yesterday, and I have it pretty much fixed. The problem is in the trap handling code, not wait_for(). The trap problem ends up corrupting the jobs data structure, which is why wait_for misbehaves. 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/
