Some time ago I wrote under this subject about a crash of sysinst on
sparc, on the netbsd-1-6 branch, that I was trying to debug.
Well I've now got a 100% reproducible crash of sysinst on alpha (also on
the netbsd-1-6 branch of course) that seems to be happening in exactly
the same place as it does on the sparc, at least given the hints I've
got from GDB so far. I simply select the "Utilities" menu, then the
"Logging functions" menu, then try to exit the latter and SIGSEGV
causing the crash occurs almost immediately. This is a most unfortunate
place for it to crash because I'm trying to debug another problem which
I've added some more logging output to help with.... :-(
I just wanted to post again about my methodology of building a
GDB-friendly version of "ramdiskbin" before I send a PR because I'm
having some trouble getting GDB to work consistently on the alpha.
First note I already have things arranged such that CFLAGS already
includes "-g" (I'm always building everything with '-g' now! ;-)
Then what I'm doing is going into $MAKEOBJDIRPREFIX to the location
where the crunchgen'ed binary is ultimately built (which is
.../distrib/alpha/instkernel/ramdisk for the alpha) and then running:
$TOOLSDIR/bin/nbmake-alpha -f ramdiskbin.mk clean
$TOOLSDIR/bin/nbmake-alpha -f ramdiskbin.mk STRIP=: all
However on the alpha I have some troubles with undefined symbols in
dd.cro and pax.cro. I have to re-compile dd's objects with
'DBG=-DNO_CONV' and pax's objects with 'DBG=-DSMALL' to work around
this. Unfortunately the result has a radically different stack
backtrace, presumably because my re-compiled binary is too different
from the one that generated the core. I don't remember having this
problem on the sparc, and as you can see in my original post[1] there is
a full stack backtrace.
Initial stack backtrace on alpha from the original binary with no
debugging symbols:
#0 0x1201055e0 in process_menu ()
#1 0x1201422fc in makech (wy=538678904)
at /proven/work/woods/m-NetBSD-1.6/lib/libcurses/refresh.c:484
warning: Hit heuristic-fence-post without finding
warning: enclosing function for address 0x120386000
This warning occurs if you are debugging a function without any symbols
(for example, in a stripped executable). In that case, you may wish to
increase the size of the search with the `set heuristic-fence-post' command.
Otherwise, you told GDB there was a function where there isn't one, or
(more likely) you have encountered a bug in GDB.
Stack backtrace from the re-compiled alpha binary with debugging symbols:
#0 0x1201055e0 in opt_act_10_2 ()
#1 0x1201422fc in winsdelln (win=0x2000000, lines=28)
at /proven/work/woods/m-NetBSD-1.6/lib/libcurses/insdelln.c:100
Cannot access memory at address 0xfffffffffffffffd
[1] my original post about the sysinst bug on sparc is here:
http://mail-index.netbsd.org/current-users/2003/06/08/0007.html
--
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com> Secrets of the Weird <woods@weird.com>