Greywolf wrote:
> 
> On Thu, 31 Jan 2002, Randall Stewart wrote:
> # 1) It seems that since I have switched to building the
> #    kernel with a -g/DEBUG option set I end up compiling
> #    about 3 or 4 times until I get a success. The failed
> #    attempts ususally end with a SIGBUS or some other such
> #    thing (error 139 and a core). This seems to happen during
> #    the ld of the kernel. I have tried playing a bit with the
> #    ulimits to see if it is something like that .. but no luck
> #    yet. The machine is not swapping (its got 64Meg) and the loader
> #    is getting around 32+ meg... Anyone have any idea what tuneable
> #    I need to tweak to get a compile every time :-0
> 
> Have you verified that your memory is good?  This looks like a bad
> memory error to me, especially since the loader is reporting less
> memory than you actually have.
> 
Well.. I suppose I can run a sun diag on the memory from the
boot rom.. I say 32+ meg just because I am using top to watch
ld grow.. I will run a diag out of the eeprom and see if
it says anything bad about the memory....


> # 2) When I crash into DDB I have a nice stack trace and such
> #    but after reboot 0x100 and then in to gdb netbsd.gdb with the core I
> #    can't trace the stack... The last time I wrote down the stack
> #    trace and was able to debug with the addresses and such and
> #    figure out my foobar.. but this is a real pain and makes it
> #    difficult to say the least... when I do the ps -.... to
> #    get the process addresses they all show up as 0... Any ideas
> #    on how I can make my kdb a bit easier? I am sure I will
> #    be in it a few more times before my SCTP work is over :0
> 
> Does it actually dump a core properly?  Does savecore recover it?
> ...are you calling gdb correctly?


Well I am just following the guide off the net

gdb netbsd.gdb
target kcore netbsd.7.core

note: I move and uncompressed the core and

ps -ax -O paddr -M netbsd.7.core 

to get out the proc... but all addresses are 0.

I was able to grunge through and get the information and 
trouble shoot the problem though.. so things did line up I just
can't do a backtrace...

R

-- 
Randall R. Stewart
randall@stewart.chicago.il.us 815-342-5222 (cell phone)