[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Current panics
On Sat, Nov 21, 2009 at 03:06:05AM +0300, Aleksej Saushev wrote:
> Manuel Bouyer <bouyer%antioche.eu.org@localhost> writes:
> > On Fri, Nov 20, 2009 at 09:57:01PM +0100, Manuel Bouyer wrote:
> >> On Fri, Nov 20, 2009 at 08:54:00PM +0300, Aleksej Saushev wrote:
> >> > Is there any way to associate addresses to line numbers?
> >> The only way I know is with gdb, but this needs a kernel compiled with -g.
> > Wit the right kenrel config file I get:
> > (gdb) l *(vn_open+320)
> > 0xc0462edd is in vn_open (/home/bouyer/HEAD/src/sys/kern/vfs_vnops.c:159).
> > 154 ndp->ni_cnd.cn_flags |= FOLLOW;
> > 155 }
> > 156
> > 157 VERIEXEC_PATH_GET(ndp->ni_dirp, ndp->ni_segflg,
> > ndp->ni_dirp, path);
> > 158
> > 159 error = namei(ndp);
> > 160 if (error)
> > 161 goto out;
> > 162
> > 163 vp = ndp->ni_vp;
> > So it could be in namei(). If you still have your netbsd.gdb around
> > could you confirm it (in my binary the address don't match exactly to
> > what you reported) ?
> Unfortunatly, I don't have it. This is the importance of having clear
> documentation what data are necessary for troubleshooting, if I knew
> it in the morning, I'd preserve this file. (Why not install it to "/"?
> To "/var/something"? For debug kernels it is reasonable. At least, some
> knob to do it might be useful.)
Well, it's big and not so usefull without the source tree from which it
was built ...
> The kernel in consideration is built with -g (it isn't the first one in
> this crashing series). Is it useful somehow without .gdb?
I don't think as it has been stripped.
> I don't have enough gdb skills, can you point to more extensive cheat
> sheet or provide instructions? (I remember there were some on the web
> site, but they were out of date past summer.)
> > namei() does a VREF which is atomic_inc_uint(&vp->v_usecount).
> > I guess vp is NULL; extracting dmesg
> > from the core dump to get the fault address could confirm it.
> Do you mean this?
> $ dmesg -M netbsd.43.core -N netbsd.43
> dmesg: kvm_read: Undefined error: 0
> dmesg: kvm_read:
Since the tools on a live system have been moved away from kmem
groveling, kvm support if broken and gets unoticed. That's unfortunate;
I don't know if some regression tests could be written for that ?
> $ crash -M netbsd.43.core -N netbsd.43
> Crash version 5.99.22, image version 5.99.22.
> System panicked: dump forced via kernel debugger
> Backtrace from time of crash is available.
> crash> dmesg 1024
> /home: replaying log to disk
> i915drm0: interrupting at ioapic0 pin 16
> uvm_fault(0xe552b0e4, 0, 2) -> 0xe
> fatal page fault in supervisor mode
> trap type 6 code 2 eip c04a62b4 cs 8 eflags 210206 cr2 14 ilevel 0
Ok, the fauling address is 0x14.
(gdb) print/x &((struct vnode *)0)->v_uobj.uo_refs
$1 = 0x14
So this is another hint that the issue is with a NULL vnode.
Why it's NULL, this I don't know.
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
NetBSD: 26 ans d'experience feront toujours la difference
Main Index |
Thread Index |