From owner-freebsd-threads@FreeBSD.ORG Thu Sep 16 22:46:13 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 47B8916A4CE; Thu, 16 Sep 2004 22:46:13 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2010543D31; Thu, 16 Sep 2004 22:46:13 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1]) i8GMkBMb073822; Thu, 16 Sep 2004 22:46:12 GMT (envelope-from davidxu@freebsd.org) Message-ID: <414A17C8.30703@freebsd.org> Date: Fri, 17 Sep 2004 06:46:32 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.1) Gecko/20040730 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer 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> In-Reply-To: <414A0EB4.5060304@elischer.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 22:46:13 -0000 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. 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/() ) *