SIGILL @ pthread_create() after execv -FIXED-

[Julian Elischer]

Daniel Eischen wrote:

>On Fri, 17 Sep 2004, David Xu wrote:
>
>
>>Daniel Eischen wrote:
>>
>>
>>>We do that in fork().  Is execv() not being done after a fork()?
>>>
>>>
>>>
>>>
>>Joost calls execv() directly in threaded process, he did not go through
>>fork() ->execv() path.
>>
>
>Yes, Julian just emailed me similarly.  In that case, I think we need
>to wrap execve() and set the kernel signal mask to the threads signal
>mask.  We don't need all the single threading stuff that is in our
>wrapped fork(); just __sys_sigprocmask() should be sufficient.  Right?
>

We would need to ensure that there is no chance that we could be 
switched to another kernel thread between the two calls.

In general I'd prefer it if we had a way that worked even if the 
userland screwed up..
execve is often a way in which daemons recover when they feel that they  
have messed up in some way...

e.g.:
panic()
{
       log("help I've fallen over and I can't get up");
       execve( me, argc, argv, envpp);  /* or whatever the args are ..ok 
so I need to write more userland stuff */_
}
do we trust userland that much?
 
does the signal therad just enable ALL signals?
does it not maks those for which we have no consumers?

I'd still prefer to do things that work for libthr as well as libpthread.


_