Date: Thu, 16 Sep 2004 16:09:23 -0700 From: Julian Elischer <julian@elischer.org> To: David Xu <davidxu@freebsd.org> Cc: freebsd-threads@freebsd.org Subject: Re: SIGILL @ pthread_create() after execv -FIXED- Message-ID: <414A1D23.6070603@elischer.org> In-Reply-To: <414A17C8.30703@freebsd.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> <414A17C8.30703@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
David Xu wrote:
> 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.
FOr exit() it would be ok to ignore it but for exec() we need some
information..
maybe we need to catch teh exec call in teh library and make sure that
it passes the right information down
My suggestion in kse is to get the signal thread to have that mask and
then the signal thread could pass it to the process as a whole..
in fact, shuoldn't the signal thread have a mask that could be set to
the current mask whenever threas chang etheir requirements?
the signal thread could do:
if (we woke up)
if (process is exiting)
set mask of curthread->td_proc->p_singlethread to my mask..
for libthr the behaviour would have to be to collect all the masks
together as each thread exits..
hmm hang on..
that would work for all cases...
if every exiting thread in this situation or'd it's mask of acceptabile
signals to teh processe's mask.
then by the end, we'd have a mask of all accepted signals..
For KSE processes all threads except the signal thread would add nothing
but the algorythm would still work...
david.. I assume the waiting signal thread ahs teh mask it needs as part
of its arguments and can use this..?
>
>
> 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?414A1D23.6070603>