bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Possible bug: Race condition when calling external commands during t


From: Linda Walsh
Subject: Re: Possible bug: Race condition when calling external commands during trap handling
Date: Mon, 21 May 2012 17:06:28 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.24) Gecko/20100228 Lightning/0.9 Thunderbird/2.0.0.24 Mnenhy/0.7.6.666



Andreas Schwab wrote:

Bob Proulx <address@hidden> writes:

And lastly I will comment that you are doing quite a bit inside of an
interrupt routine.  Typically in a C program it is not safe to perform
any operation that may call malloc() within an interupt service
routine since malloc isn't reentrant.  Bash is a C program and I
assume the same restriction would apply.

Traps are executed only at command boundaries.  Executing them in a
signal handler would make them completely unusable, of course.

Andreas.

---
        But a trap HAS to be executed in the trap handler
to reset it self, otherwise you risk losing a signal.

        As soon as you exit your trap handler,
your trap handler had better already be in place.
If it isn't and trap comes in before you catch it,
you've lost it.

the "perlipc" manpage explains some of the details
behind this problem.  Their suggested handler:

           use POSIX ":sys_wait_h";
           sub REAPER {
               my $child;
               # If a second child dies while in the signal handler caused by 
the
               # first death, we won't get another signal. So must loop here 
else
               # we will leave the unreaped child as a zombie. And the next time
               # two children die we get another zombie. And so on.
               while (($child = waitpid(-1, WNOHANG)) > 0) {
                   $Kid_Status{$child} = $?;
               }
               $SIG{CHLD} = \&REAPER;  # still loathe SysV
           }
           $SIG{CHLD} = \&REAPER;
           # do something that forks...

---
I think it was sysV compat libs that are unsafe (you have to reset
handler each signal)...




reply via email to

[Prev in Thread] Current Thread [Next in Thread]