From owner-freebsd-threads@FreeBSD.ORG Thu Sep 16 22:07:50 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 682DD16A4CE; Thu, 16 Sep 2004 22:07:50 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6CB5643D54; Thu, 16 Sep 2004 22:07:49 +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 1F7D67A3D2; Thu, 16 Sep 2004 15:07:49 -0700 (PDT) Message-ID: <414A0EB4.5060304@elischer.org> Date: Thu, 16 Sep 2004 15:07:48 -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: Joost Bekkers 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> In-Reply-To: <20040916211757.GA4830@bps.jodocus.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: David Xu 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:07:50 -0000 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? > > >