dtrace ustack kernel panic
kostikbel at gmail.com
Sat Jul 30 19:26:51 UTC 2011
On Sat, Jul 30, 2011 at 12:05:33PM -0700, maestro something wrote:
> >> Have you started kgdb with the correct kernel and core file?
> >> If yes, then I am out of ideas.
> > I hope so, I only recompiled the kernel once according to the DTRACE wiki
> > instructions and I certainly only have one /var/crash/vmcore.* file.
> > I'll try recompiling the kernel with -O1 and try again. In the meantime,
> > I'm wondering whether I'm really the only/first one that ran into this
> > problem or if there are people that actually successfully used the ustack()
> > target on freebsd-8.2?
> I could not get the information even after recompiling the kernel here is
> the relevant (I think information).
> fb82i386# cat /etc/make.conf
> CFLAGS= -O
> (accodring to man make.conf only -O and -O2 is supported for CFLAGS anyways)
> kernel.debug is the newly compiled kernel (according to the timestamp)
> fb82i386# kgdb kernel.debug /var/crash/vmcore.0
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 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
> 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-marcel-freebsd"...
> Unread portion of the kernel message buffer:
> kernel trap 12 with interrupts disabled
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address = 0x108
> fault code = supervisor write, page not present
> instruction pointer = 0x20:0xc1100847
> stack pointer = 0x28:0xcd39a9e4
> frame pointer = 0x28:0xcd39a9fc
> code segment = base 0x0, limit 0xfffff, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags = resume, IOPL = 0
> current process = 1060 (nc)
> trap number = 12
> panic: page fault
> cpuid = 0
> KDB: stack backtrace:
> #0 0xc09036a7 at kdb_backtrace+0x47
> #1 0xc08d1a07 at panic+0x117
> #2 0xc0c158c3 at trap_fatal+0x323
> #3 0xc0c15bc0 at trap_pfault+0x2f0
> #4 0xc0c1612a at trap+0x48a
> #5 0xc0bfc97c at calltrap+0x6
> #6 0xc10e99db at dtrace_panic+0x1b
> #7 0xc10e9a0d at dtrace_assfail+0x2d
> #8 0xc10fa6a6 at dtrace_probe+0xfd6
> #9 0xc1237ce4 at systrace_probe+0x84
> #10 0xc090f63f at syscallenter+0x47f
> #11 0xc0c15c14 at syscall+0x34
> #12 0xc0bfca11 at Xint0x80_syscall+0x21
> Uptime: 2m39s
> Physical memory: 239 MB
> Dumping 78 MB: 63 47 31 15
> (kgdb) where
> #0 doadump () at pcpu.h:231
> #1 0xc08d17a3 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:419
> #2 0xc08d1a40 in panic (fmt=Variable "fmt" is not available.
> ) at /usr/src/sys/kern/kern_shutdown.c:592
> #3 0xc0c158c3 in trap_fatal (frame=0xcd39a9a4, eva=264) at
> #4 0xc0c15bc0 in trap_pfault (frame=0xcd39a9a4, usermode=0, eva=264) at
> #5 0xc0c1612a in trap (frame=0xcd39a9a4) at
> #6 0xc0bfc97c in calltrap () at /usr/src/sys/i386/i386/exception.s:166
> #7 0xc1100847 in dtrace_panic_trigger () from /boot/kernel/dtrace.ko
> Previous frame inner to this frame (corrupt stack?)
> (kgdb) list *dtrace_probe+0xfd6
> No source file for address 0xc10fa6a6.
> So I'm stuck at the same point.
> any other ideas?
This is i386, right ?
I think the cause is that assembler routine panic_trigger does not
establish the standard i386 frame. Basically, you need either this,
or dwarf annotations, for gdb to be able to walk over the frame.
You need to add the standard prologue
and standard epilogue
to the function. No idea whether it will continue to operate correctly
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20110730/a882f7af/attachment.pgp
More information about the freebsd-stable