SIGILL @ pthread_create() after execv -FIXED-

[Daniel Eischen]

On Fri, 17 Sep 2004, David Xu wrote:

> Julian Elischer wrote:
>
> > Ick.
> >
> >
> > Joost Bekkers wrote:
> >
> >> 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.

We do that in fork().  Is execv() not being done after a fork()?

-- 
Dan Eischen