Linking problem fixed, Tracking down Kernel bugs?

[Rob <dickrp%wckn.dorm.clarkson.edu@localhost>]

Me:
> > I get a run-time error when compiling a C++ program and linking with
> > g++.  This error is a result of a symbol, "_tgetstr" that can not be found
> > during dynamic linking.  The symbol is needed by /usr/lib/libcurses.s0.2.1.

David Brownlee:
> Just a quick check - are you linking it with -lcurses -ltermcap?

I wasn't linking w. libtermcap.a.  Thanks.


One other question... How does one track down a bug in the kernel?
Last night, I was (tar zxf)ing a huge (X11R6) file off from an AmigaDOS
partition and my system froze (no core dump or anything).  There was no
response to ^z and all of my other screens froze as well.  There was
enough space on the target partition for the archive.

This isn't something I can make a useful bug report about because I have no
idea what caused it.  When I rebooted and tried again, tar told me that it
found an unexpected EOF.  That's fine, maybe tar crashed, but if tar went
wandering off aimlessly through my memory space, shouldn't the kernel have
sent it's proc. a SIGSEGV instead of causing my system to hang?

Is NetBSD at a state where MP is buggy or should I be looking for a problem
with my computer?  If thare hasn't been much testing w. the '060, I would like
to get my hands on some programs that intentionally do evil things that the
Kernel should detect and stop gracefully so I can see where it just crashes
and submit a useful bug report (or fix the problem myself).

-Robert Dick (dickrp%wckn.dorm.clarkson.edu@localhost)-

NetBSD-1.2, Generic Kernel, screen-3.7.1, bash-1.14.7
A3000
MK-II '060, 16 M SIMM
4 M SCZIP fast, 2 M DIP chip
Rev 8 WD SCSI chip
SCSI BUS has active terms at both ends