From owner-freebsd-threads@FreeBSD.ORG Thu Sep 16 23:09:25 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C1CC16A4CE; Thu, 16 Sep 2004 23:09:25 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id ECA3543D3F; Thu, 16 Sep 2004 23:09:23 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 848667A3D2; Thu, 16 Sep 2004 16:09:23 -0700 (PDT) Message-ID: <414A1D23.6070603@elischer.org> Date: Thu, 16 Sep 2004 16:09:23 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: David Xu 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> In-Reply-To: <414A17C8.30703@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Daniel Eischen cc: freebsd-threads@freebsd.org Subject: Re: SIGILL @ pthread_create() after execv -FIXED- X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2004 23:09:25 -0000 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/() > > > and /pthread_sigmask/() > > ) > > * > > Pending signals (see /sigpending/() > > ) > > * > >