Subject: Re: Getting information out of crash dump
To: Martin J. Laubach <mjl@emsi.priv.at>
From: Chuck Silvers <chuq@chuq.com>
List: tech-kern
Date: 04/26/1999 04:48:31
if this is the same "vrele: ref cnt" panic that was PR'd yesterday,
I'm looking at it too.

the fact that the full stack wasn't displayed is just a bug
that we'll fix.  someone is already looking into why gdb can't do it.
if ddb can't either then we'll fix that too.

in gdb I did "i r" to get %ebp, then dumped out a few hundred bytes after
that with "x/200x ADDRESS".  %ebp is the frame pointer, which points to
the previous frame pointer, which points to the frame pointer before that...
you get the idea.  the 4 bytes after each frame pointer is the return address,
so you can do "x/i ADDRESS" on each return address to get the names of the  
functions.  when the frame pointer becomes less that 0xf0000000 (at least
on i386) then you can stop, since that's when you've walked all the way out
of the kernel back into the usermode stack.

in this dump, the rest of the stack trace is:
frame ptr	pc		function
0xf3ef1e10	0xf0100f1d	calltrap
0xf3ef1e24	0xf018ba69	panic
0xf3ef1e50	0xf01a36c0	vrele+80
0xf3ef1f24	0xf01a8497	rename_files+959
0xf3ef1f3c	0xf01a80bd	sys_rename+21
0xf3ef1fa8	0xf027ed26	syscall+526
0xefbfdd64	0xf0100fc9	syscall1+31

this corresponds to the vrele() in this bit at the end of
kern/vfs_syscalls.c:rename_files()

out1:
	if (fromnd.ni_startdir)
		vrele(fromnd.ni_startdir);
	FREE(fromnd.ni_cnd.cn_pnbuf, M_NAMEI);
	return (error == -1 ? 0 : error);


that's as much as I've gotten so far...

-Chuck


"Martin J. Laubach" writes:
>   A friend of mine suffered a crash, and since I talked him into
> trying netbsd, I thought I'd better check up on his problem. So
> here I am with a crash dump -- but how the hell do I get a stack
> backtrace out of it. All I have been able to get is:
> 
> | asparagus:1 [~/local/tmp3] % gdb netbsd
> | GNU gdb 4.17
> | ...
> | (gdb) target kcore netbsd.0.core
> | panic: vrele: ref cnt
> | #0  0xf02d6bbc in db_last_command ()
> | (gdb) where
> | #0  0xf02d6bbc in db_last_command ()
> | #1  0x2206000 in ?? ()
> | #2  0xf027491f in cpu_reboot ()
> | #3  0xf011855a in db_reboot_cmd ()
> | #4  0xf0118170 in db_command ()
> | #5  0xf01183aa in db_command_loop ()
> | #6  0xf011ae82 in db_trap ()
> | #7  0xf02720b2 in kdb_trap ()
> | #8  0xf027e5b0 in trap ()
> 
>   which isn't really saying all that much, is it. Is there a magic
> incantation to actually get useful data out the dump?
> 
> 	mjl
>