NetBSD Problem Report #68

From gnats  Wed Jan 12 18:59:14 1994
Received: from bloom-beacon.mit.edu (BLOOM-BEACON.MIT.EDU [18.70.0.232]) by sun-lamp.cs.berkeley.edu (8.6.4/8.6.4) with SMTP id SAA00842 for <gnats-bugs@sun-lamp.cs.berkeley.edu>; Wed, 12 Jan 1994 18:49:57 -0800
Message-Id: <199401130234.VAA00235@orchard.medford.ma.us>
Date: Wed, 12 Jan 1994 21:34:09 -0500
From: sommerfeld@orchard.medford.ma.us
Reply-To: sommerfeld@orchard.medford.ma.us
To: gnats-bugs@sun-lamp.cs.berkeley.edu
Subject: call of null function ptr not handled well by i386 ddb.
X-Send-Pr-Version: 3.01.6

>Number:         68
>Category:       kern
>Synopsis:       call through null function ptr in kernel confuses ddb
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    gnats-admin
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Jan 12 19:05:03 +0000 1994
>Closed-Date:    Tue Mar 31 08:14:33 +0000 1998
>Last-Modified:  Sun Mar 03 17:53:14 +0000 2013
>Originator:     Bill Sommerfeld
>Release:        -current
>Organization:
	none
>Environment:

System: NetBSD orchard.medford.ma.us 0.9a ORCHARD#17 i386


>Description:
	A call through a null function pointer in the kernel results
in a trap into ddb, which immediately attempts to disassemble the pc of
the fault, which is zero; this generates a recursive fault which makes 
it hard to get at the original fault..

>How-To-Repeat:
	add a int (*fn)() = NULL; (*fn)(); to your kernel, either
	intentionally or accidentally.
>Fix:
	haven't looked at code yet; ddb should "step carefully" when 
	disassembling to avoid this kind of thing.


>Release-Note:
>Audit-Trail:

From: sommerfeld@orchard.medford.ma.us (Bill Sommerfeld)
To: mycroft@gnu.ai.mit.edu
Subject: Re:  kern/68: call of null function ptr not handled well by i386 ddb.
Date: Thu, 13 Jan 1994 10:17:06 -0500

    At least on *my* machine, when you fault in DDB, it longjmp()s back to
    the top-level reader and leaves you in the same state as when you
    entered DDB.

    How old is your kernel?

 Very recent (2-3 days old).

 It wasn't at *all* obvious that DDB returned to the original state,
 and the traceback stopped at trap() rather than showing where the
 call-through-NULL came from.  (a:

 	printf("Fault in DDB caught and ignored\n");

 just before the longjmp would go a long way towards fixing this..

 The real bug, IMHO, is that DDB doesn't deal well with a call through
 NULL in the kernel.

 (the actual cause of the call through NULL is unknown, though I
 suspect version skew between .o's; it stopped happening when I
 reconfiged and rebuilt the kernel from scratch).

 It's probably obvious, but both faults went through this path,

 			printf("vm_fault(%x, %x, %x, 0) -> %x\n",
 			       map, va, ftype, rv);
 			goto we_re_toast;

 where "map" was &vmspace0, va was zero, and I don't recall what ftype
 and rv were..

 					- Bill
State-Changed-From-To: open->closed 
State-Changed-By: thorpej 
State-Changed-When: Tue Mar 31 00:14:33 PST 1998 
State-Changed-Why:  
Fixed. 

>Unformatted:

Home	PR Database Search