In article <434694D1.10803@spg.tu-darmstadt.de>,
Hauke Fath  <hf@spg.tu-darmstadt.de> wrote:
>Rui Paulo wrote:
>> On 2005.10.07 15:43:00 +0200, Hauke Fath wrote:
>> | Christos Zoulas wrote:
>> | >In article <43466AC0.9000506@spg.tu-darmstadt.de>,
>> | >Hauke Fath  <hf@spg.tu-darmstadt.de> wrote:
>> | >
>> | >>New is that with 14.3, the Java IDE works nicely on NetBSD. Don't run 
>> | >>'bench', though, as it panics the machine.
>> | >
>> | >What's the panic?
>> | 
>> | A bit weird:
>> 
>> Did you removed the symbol information using strip(1) ?
>
> From the kernel? No. That's why I said 'weird' - here is a 'normal' 
>stack trace from the same kernel:
>
>root file system type: ffs
>Enter root password, or ^D to go multi-user
>Password:~#
>The following connections are open:
>   #0 client-session (t4 r0 i0/0 o0/0 fd 6/7)
>~Stopped at      netbsd:cpu_Debugger+0x4:        leave
>db> t
>cpu_Debugger(246,c0716e6c,c0716e40,206,c179f840) at netbsd:cpu_Debugger+0x4
>comintr(c1a2fe00,0,2d450010,30,6b4d0010) at netbsd:comintr+0x692
>Xintr_legacy4() at netbsd:Xintr_legacy4+0xa9
>--- interrupt ---
>cpu_switch(c066d400,0,c0716f38,c030da76,1) at netbsd:cpu_switch+0x9f
>ltsleep(c066d240,4,c05cd141,0,0) at netbsd:ltsleep+0x327
>uvm_scheduler(c066d220,0,c067161c,c05b598a,0) at netbsd:uvm_scheduler+0x74
>main(0,0,0,0,0) at netbsd:main+0x696
>db>
>	hauke

Hmm, the core is not very helpful (at least I cannot make sense out of it)
because:

$ gdb netbsd.0
GNU gdb 5.3nb1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386--netbsdelf"...(no debugging symbols found)...
(gdb) target kcore netbsd.0.core
#0  0x3fed0000 in ?? ()
(gdb) where
#0  0x3fed0000 in ?? ()
#1  0xc0396f3b in cpu_reboot ()
#2  0xc02d1f58 in db_sync_cmd ()
#3  0xc02d19a7 in db_command ()
#4  0xc02d16ba in db_command_loop ()
#5  0xc02d478c in db_trap ()
#6  0xc0394692 in kdb_trap ()
#7  0xc039eea4 in trap ()
(gdb) quit

Now the stack trace you posted has addresses in the 0xa and 0xbc range
which does not make sense because the kernel is linked at 0xc0100000,
and the addresses are below that. This is why there are no symbols.

christos