SIGILL @ pthread_create() after execv -FIXED-
davidxu at freebsd.org
Thu Sep 16 15:46:13 PDT 2004
Julian Elischer wrote:
> 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
> 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?
I think this becauses the M:N thread masks all signals except SIGSTOP
the real signal mask in userland needs to be set back to kernel,
provide a wrapper for execv syscall, Dan? fix me if I am wrong.
The initial thread of the new process shall inherit at least the
from the calling thread:
Signal mask (see /sigprocmask/()
Pending signals (see /sigpending/()
More information about the freebsd-threads