Date: Fri, 17 Sep 2004 06:46:32 +0800 From: David Xu <davidxu@freebsd.org> To: Julian Elischer <julian@elischer.org> Cc: freebsd-threads@freebsd.org Subject: Re: SIGILL @ pthread_create() after execv -FIXED- Message-ID: <414A17C8.30703@freebsd.org> In-Reply-To: <414A0EB4.5060304@elischer.org> References: <20040912141838.GA89862@bps.jodocus.org> <414489FF.3090705@elischer.org> <414645C8.8070001@elischer.org> <20040914140002.GA32528@bps.jodocus.org> <41494310.40907@elischer.org> <20040916162828.GA855@bps.jodocus.org> <20040916211757.GA4830@bps.jodocus.org> <414A0EB4.5060304@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote:
> Ick.
>
>
> Joost Bekkers wrote:
>
>> On Thu, Sep 16, 2004 at 06:28:28PM +0200, Joost Bekkers wrote:
>>
>>
>>> On Thu, Sep 16, 2004 at 12:38:56AM -0700, Julian Elischer wrote:
>>>
>>>
>>>> I checked in David's patch, which may fox this..
>>>> try -current .
>>>>
>>>>
>>>
>>> I'm not experiencing the problem anymore.
>>>
>>>
>>
>>
>> Celebrated too soon....
>>
>> Signals are not being delivered to the process after it did
>> its execv.
>>
>> The only signal that seems to be working is KILL (-9)
>>
>
> the man page is: (for execve)
> Signals set to be ignored in the calling process are set to be
> ignored in
> the new process. Signals which are set to be caught in the calling
> process image are set to default action in the new process image.
> Blocked signals remain blocked regardless of changes to the signal
> action. The signal stack is reset to be undefined (see
> sigaction(2) for
> more information).
>
> so we need to keep track of all signals accepted by the process (which
> is an
> OR of the signals accepted by all the threads) and set it back to that
> state
> regardless of what thread is doing the exit.
> (yuck that is quite a difficult question) I wonder if the "signal
> gatherring thread"
> has that info?
>
> Maybe if the signal thread exits it should look to see if the process
> is exec/exiting
> (by looking at the thread_single mode) and transfer its mask to teh
> 'survicor' thread?
>
> David?
>
I think this becauses the M:N thread masks all signals except SIGSTOP
and SIGKILL,
the real signal mask in userland needs to be set back to kernel,
libpthread should
provide a wrapper for execv syscall, Dan? fix me if I am wrong.
Posix says:
The initial thread of the new process shall inherit at least the
following attributes
from the calling thread:
*
Signal mask (see /sigprocmask/()
<http://www.opengroup.org/onlinepubs/009695399/functions/sigprocmask.html>;
and /pthread_sigmask/()
<http://www.opengroup.org/onlinepubs/009695399/functions/pthread_sigmask.html>)
*
Pending signals (see /sigpending/()
<http://www.opengroup.org/onlinepubs/009695399/functions/sigpending.html>)
*
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?414A17C8.30703>