NetBSD Problem Report #6688

Received: (qmail 28791 invoked from network); 30 Dec 1998 09:44:35 -0000
Message-Id: <199812300942.EAA02624@dbj.ne.mediaone.net>
Date: Wed, 30 Dec 1998 04:42:54 -0500 (EST)
From: dbj@netbsd.org
Reply-To: dbj@netbsd.org
To: gnats-bugs@gnats.netbsd.org
Cc: dbj@netbsd.org
Subject: ddb backtrace after address trap skips faulting address
X-Send-Pr-Version: 3.95

>Number:         6688
>Category:       port-next68k
>Synopsis:       ddb backtrace after address trap skips faulting address
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    port-next68k-maintainer
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Dec 30 01:50:01 +0000 1998
>Closed-Date:    Tue Aug 03 08:22:10 +0000 1999
>Last-Modified:  Tue Aug 03 08:24:02 +0000 1999
>Originator:     Darrin B. Jewell
>Release:        -current, as of Wed Dec 30 09:36:24 UTC 1998
>Organization:

>Environment:

NetBSD/next68k.

NetBSD 1.3I (GENERIC) #124: Wed Dec 30 04:11:59 EST 1998
    dbj@dbj.ne.mediaone.net:/usr/incoming/cvs.netbsd.org/src/sys/arch/next68k/compile/GENERIC

Problem may be shared with other m68k ports.

>Description:
When I use ddb to trace after a kernel trap, it skips
the name of the routine in which the trap actually occurred.

>How-To-Repeat:

I made the following temporary change to the next68k's
cpu_startup routine:

$ cvs diff -u -C 5 machdep.c
Index: machdep.c
===================================================================
RCS file: /cvsroot/src/sys/arch/next68k/next68k/machdep.c,v
retrieving revision 1.10
diff -u -u -C5 -r1.10 machdep.c
cvs server: conflicting specifications of output style
*** machdep.c   1998/11/14 04:32:50     1.10
--- machdep.c   1998/12/30 09:14:53
***************
*** 505,514 ****
--- 505,517 ----
        /*
         * Set up buffers, so they can be used to read disk labels.
         */
        bufinit();

+       printf("Forcing jump to page zero at address 0x33\n");
+       (*((void (*)(void))0x33))();    /* test seg fault */
+ 
        /*
         * Configure the system.
         */
        configure();
  }


Here's a log of the boot sequence:

Copyright (c) 1996, 1997, 1998
    The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
    The Regents of the University of California.  All rights reserved.

NetBSD 1.3I (GENERIC) #124: Wed Dec 30 04:11:59 EST 1998
    dbj@dbj.ne.mediaone.net:/usr/incoming/cvs.netbsd.org/src/sys/arch/next68k/compile/GENERIC
NeXT/MC68040 CPU+MMU+FPU, 4k on-chip physical I/D caches
real mem  = 33546240
avail mem = 28401664
using 409 buffers containing 1675264 bytes of memory
Forcing jump to page zero at address 0x33
trap type 1, code = 0, v = 32
kernel: Address error trap
pid = 0, pc = 000E0B00, ps = 2700, sfc = 1, dfc = 1
Registers:
             0        1        2        3        4        5        6        7
dreg: 00002704 00000051 00000000 00001240 00000001 00000000 00002000 0000000C
areg: 000D8C3E 00000000 0002CBBE 0012C784 000C933C 04000000 00174F78 FFEFFFFC

Kernel stack (00174EA8):
174EA8: 000DAA72 00174EF8 00000080 00000000 00001240 00000001 00000000 00002000
174EC8: 0000000C 0002CBBE 0012C784 000C933C 04000000 04000000 00000001 00174F78
174EE8: 00001370 00000001 00000000 00000032 00002704 00000051 00000000 00001240
174F08: 00000001 00000000 00002000 0000000C 000D8C3E 00000000 0002CBBE 0012C784
174F28: 000C933C 04000000 00174F78 FFEFFFFC 00000000 2700000E 0B00200C 00000032
174F48: 000E07EB 04001000 00000000 0000006E 00169000 00000000 0000000D FFEFFFFC
174F68: 0011BE6C 04169000 03290000 02D90000 00174FAC 0001C220 001024D8 04001000
174F88: 00000000 0000006E FFEFFFFC 05FFFC96 04169000 00178000 00169000 00000000
174FA8: 0000000D 00000000 00000011 0002B2D4 00178000 00000000 00001000 00001000
174FC8: 0012CEDC 0012CEE0 00174FF4 000E0668 00178000 00001000 04001000 00000000
174FE8: 0000006E FFEFFFFC 00000000 00000000 00000000 00000000 
panic: Address error
Stopped in  at  _Debugger+0x6:  unlk    a6
db> t
_Debugger(0,174ef8,12c784,174ee4,daa92) + 6
_panic(da716,0,1240,1,0) + 52
_trap(1,0,32) + 1c8
faultstkadj(1024d8,4001000,0,6e,ffeffffc) + 0
_main(2b2d4,178000,0,1000,1000) + 50
db> 


If I use addr2line to examine the kernel at the program counter
listed in the trap printout, I get the correct address:

0$ m68k-unknown-netbsd1.3E-addr2line -e ./netbsd.gdb 000E0B00
/usr/incoming/cvs.netbsd.org/src/sys/arch/next68k/compile/GENERIC/../../../../arch/next68k/next68k/machdep.c:511

>Fix:
        Examine addrerr4060 in locore.s to see if the stack is getting
saved correctly.  I thought I fixed this once before, but I can't
find any evidence of a fix in cvs logs.
>Release-Note:
>Audit-Trail:

From: "Darrin B. Jewell" <dbj@netbsd.org>
To: gnats-bugs@gnats.netbsd.org
Cc: port-m68k@netbsd.org, "Gordon W. Ross" <gwr@netbsd.org>, scw@netbsd.org
Subject: port-next68k/6688 Re: pullup (m68k)
Date: 05 Apr 1999 03:04:17 -0400

 I just went and read the cvs log for this pullup. (included
 below)  I suspect this pullup fixes PR port-next68k/6688
 "ddb backtrace after address trap skips faulting address"
 I'll test and close the pr if that's the case.

 Thanks.

 Darrin

 "Gordon W. Ross" <gwr@netbsd.org> writes:

 > I've found this change to be quite useful.  It fixes a bug in the
 > DDB trace command that prevented backtrace through trap faults.
 > Please pull up this file:
 > 
 > /src/sys/arch/m68k/m68k/db_trace.c  1.24
 > 
 > Thanks,
 > Gordon

 ----------------------------
 revision 1.24
 date: 1999/04/04 11:33:02;  author: scw;  state: Exp;  lines: +35 -1
 Fix a problem I noticed a while back but had too many other things
 in the air to deal with it.
 Basically, following a kernel fault (eg. dereferencing a NULL pointer
 in kernel mode) a DDB 'trace' did not show the function where the
 fault occurred. For example:

         db> trace
         _Debugger()
         _panic()
         _trap()
         faultstkadj()
         _pool_drain()
         _uvm_pageout()
         _start_pagedaemon()
         _proc_trampoline()
         db>

 The 'faultstkadj()' line here is bogus. It is shown because the return
 address to 'trap()' happens to point there, and since faultstkadj() has
 no stack frame, DDB assumes it was the faulting function. In this example,
 the _real_ function was pool_reclaim(), but you would have to look at
 the program counter at the time of the fault to figure that one out.

 This fix makes the trace command do the dirty work for you by grubbing
 around in 'trap()'s argument list to find the *real* PC value at the
 time of the fault, replacing the 'faultstkadj()' line with the real
 function's name.
 ----------------------------

From: Steve Woodford <steve@mctavish.demon.co.uk>
To: "Darrin B. Jewell" <dbj@netbsd.org>
Cc: gnats-bugs@gnats.netbsd.org, port-m68k@netbsd.org,
        "Gordon W. Ross" <gwr@netbsd.org>, scw@netbsd.org
Subject: Re: port-next68k/6688 Re: pullup (m68k)
Date: Mon, 5 Apr 1999 18:23:13 +0100 (BST)

 On 5 Apr 1999, Darrin B. Jewell wrote:

 > I just went and read the cvs log for this pullup. (included
 > below)  I suspect this pullup fixes PR port-next68k/6688
 > "ddb backtrace after address trap skips faulting address"
 > I'll test and close the pr if that's the case.

 Mmm, fixing PR's. :-)

 Ok, I've requested revision 1.25 (with a change to ensure the 'fix' only
 does it's thing when the exception was in kernel mode) be pulled up.

 Cheers, Steve


State-Changed-From-To: open->closed 
State-Changed-By: dbj 
State-Changed-When: Tue Aug 3 01:22:10 PDT 1999 
State-Changed-Why:  
fixed by commit from scw as discussed in pr. 
>Unformatted:

Home	PR Database Search