Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 16 Sep 2004 15:07:48 -0700
From:      Julian Elischer <julian@elischer.org>
To:        Joost Bekkers <joost@jodocus.org>
Cc:        freebsd-threads@freebsd.org
Subject:   Re: SIGILL @ pthread_create() after execv -FIXED-
Message-ID:  <414A0EB4.5060304@elischer.org>
In-Reply-To: <20040916211757.GA4830@bps.jodocus.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>

next in thread | previous in thread | raw e-mail | index | archive | help
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?


>
>  
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?414A0EB4.5060304>