NetBSD Problem Report #36532

From woods@building.weird.com  Sat Jun 23 18:59:03 2007
Return-Path: <woods@building.weird.com>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by narn.NetBSD.org (Postfix) with ESMTP id 3541763B882
	for <gnats-bugs@gnats.netbsd.org>; Sat, 23 Jun 2007 18:59:03 +0000 (UTC)
Message-Id: <m1I2Ap4-002IwcC@building.weird.com>
Date: Sat, 23 Jun 2007 14:59:02 -0400 (EDT)
From: "Greg A. Woods" <woods@planix.com>
Sender: "Greg A. Woods" <woods@building.weird.com>
Reply-To: "Greg A. Woods" <woods@planix.com>
To: gnats-bugs@NetBSD.org
Subject: fix for a core dump in /bin/sh dotrap()
X-Send-Pr-Version: 3.95

>Number:         36532
>Category:       bin
>Synopsis:       fix for a core dump in /bin/sh dotrap()
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Jun 23 19:00:00 +0000 2007
>Closed-Date:    
>Last-Modified:  Sun Feb 21 18:10:00 +0000 2016
>Originator:     Greg A. Woods
>Release:        netbsd-4 2007/06/22
>Organization:
Planix, Inc.; Toronto, Ontario; Canada
>Environment:
System: NetBSD 
>Description:

	there's a bug in dotrap() that can cause a core dump

>How-To-Repeat:

>Fix:

	this has been sitting in my local sources for a very long time
	and I recently discovered it still needed pulling up into my
	local netbsd-4 tree too

Index: bin/sh/trap.c
===================================================================
RCS file: /cvs/master/m-NetBSD/main/src/bin/sh/trap.c,v
retrieving revision 1.33
diff -u -r1.33 trap.c
--- bin/sh/trap.c	15 Jul 2005 17:23:48 -0000	1.33
+++ bin/sh/trap.c	10 Feb 2007 17:17:10 -0000
@@ -413,7 +413,19 @@
 		}
 		gotsig[i - 1] = 0;
 		savestatus=exitstatus;
-		evalstring(trap[i], 0);
+/*
+ * #3  0x00000001200162f8 in dotrap ()
+ *     at /building/work/woods/m-NetBSD-1.6/bin/sh/trap.c:398
+ * 398              evalstring(trap[i], 0);
+ * (gdb) print i
+ * $1 = 1
+ * (gdb) print trap[i]
+ * $2 = 0x0
+ */
+		if (trap[i])
+			evalstring(trap[i], 0);
+		else
+			error("got sig %d, but no trap command set!", i);
 		exitstatus=savestatus;
 	}
 done:

>Release-Note:

>Audit-Trail:

State-Changed-From-To: open->feedback
State-Changed-By: christos@netbsd.org
State-Changed-When: Sun, 24 Jun 2007 14:35:12 -0400
State-Changed-Why:
do you have a way to reproduce it?


From: "Greg A. Woods" <woods@planix.com>
To: NetBSD GNATS <gnats-bugs@NetBSD.org>
Cc: <gnats-admin@netbsd.org>, <christos@netbsd.org>
Subject: Re: bin/36532 (fix for a core dump in /bin/sh dotrap())
Date: Sun, 24 Jun 2007 15:13:09 -0400

 --pgp-sign-Multipart_Sun_Jun_24_15:13:09_2007-1
 Content-Type: text/plain; charset=US-ASCII
 Content-Transfer-Encoding: quoted-printable

 At Sun, 24 Jun 2007 18:35:13 +0000 (UTC), christos@netbsd.org wrote:
 Subject: Re: bin/36532 (fix for a core dump in /bin/sh dotrap())
 >=20
 > Synopsis: fix for a core dump in /bin/sh dotrap()
 >=20
 > State-Changed-From-To: open->feedback
 > State-Changed-By: christos@netbsd.org
 > State-Changed-When: Sun, 24 Jun 2007 14:35:12 -0400
 > State-Changed-Why:
 > do you have a way to reproduce it?

 No, I don't unfortunately.  I think it may only occur in some narrow
 window.  I captured the one core dump and backtrace by pure luck.

 --=20
 						Greg A. Woods

 H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods@robohack.ca>
 Planix, Inc. <woods@planix.com>       Secrets of the Weird <woods@weird.com>

 --pgp-sign-Multipart_Sun_Jun_24_15:13:09_2007-1
 Content-Type: application/pgp-signature
 Content-Transfer-Encoding: 7bit

 -----BEGIN PGP SIGNATURE-----
 Version: PGPfreeware 5.0i for non-commercial use
 MessageID: 5rH0OqFgTT6RSisSFW0pRETR7GnWz/Nz

 iQA/AwUBRn7CRWZ9cbd4v/R/EQLSVQCg2AxCP1NVgbNPxaSsZ62iINZsr+8An1iz
 ji/Z9cNp9pC7i0tNM0LZQq1r
 =tu8E
 -----END PGP SIGNATURE-----

 --pgp-sign-Multipart_Sun_Jun_24_15:13:09_2007-1--

State-Changed-From-To: feedback->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Thu, 10 Apr 2008 02:21:33 +0000
State-Changed-Why:
Feedback received.


From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/36532 (fix for a core dump in /bin/sh dotrap())
Date: Mon, 22 Feb 2016 01:06:20 +0700

 I don't have a test case to cause this, but I have a hypothesis about
 how it might happen.

 If sh just happens to be executing a "trap - N" command when
 signal N arrives, then trap[N] will be set to NULL, at the
 same time as gotsig[N] (really N-1, but that's irrelevant)
 will get set (along with pendingsigs).

 When the shell gets to process the pending signal, it assumes that
 if trap[N] is NULL, then the signal state for the process is SIG_DFL,
 (which it does get set to, but possibly, just a little too late) and
 so not eligible for delivery to the shell.)

 Assuming this is the cause, then the patch supplied (minus the error()
 when trap[N] is NULL - just do nothing in that case, ignore the signal,
 it is the best we can do (other than possibly kill(getpid(), N) to
 cause the signal to be redelivered, and take its normal default action.

 Another way, would be to do the setsig() first (when going to SIG_DFL
 or SIG_IGN only - though the SIG_IGN case doesn't cause a problem, there
 the trap is just an empty string, which can be processed, doing nothing,
 without problems) then process pending signals (if any) and only after we
 know that we cannot have signal N delivered, and that there isn't one
 pending, then set trap[N] to NULL.

 There is no (rational) way to fix this just by reordering the setsig()
 and trap[N] = NULL statements, the signal might already be pending,
 it could have arrived from any time after the last check of pendingsigs
 until the setsig() is eventually done.

 kre

>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.