From owner-freebsd-threads@FreeBSD.ORG Thu Sep 16 22:58:53 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 3938716A4CF; Thu, 16 Sep 2004 22:58:53 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id C986043D39; Thu, 16 Sep 2004 22:58:52 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) i8GMwoML026293; Thu, 16 Sep 2004 18:58:50 -0400 (EDT) Date: Thu, 16 Sep 2004 18:58:50 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: David Xu In-Reply-To: <414A17C8.30703@freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: Julian Elischer 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 Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2004 22:58:53 -0000 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