Date: Fri, 29 Jul 2011 14:28:30 -0700 From: maestro something <maestro82@gmail.com> To: freebsd-stable@freebsd.org Subject: Re: dtrace ustack kernel panic Message-ID: <CAJ_JOqv5=8Q-7=4YfGu4aKY9duRfhk_Ra4MG_HDs0uoe5_Dg1Q@mail.gmail.com> In-Reply-To: <4E2E9F60.1060808@FreeBSD.org> References: <CAJ_JOqvEmXBTBABhUcJ66=bh9%2B8S%2BC9v30hXxVZiCXuEpGPJ1A@mail.gmail.com> <4E2E9F60.1060808@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
trying to do so I don't really find my way around. This is what I get when I
run kgdb
On startup the assert frame is #7 and the probe frame is #8.
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
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-marcel-freebsd"...
Unread portion of the kernel message buffer:
kernel trap 12 with interrupts disabled
- Show quoted text -
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:0xc11012d7
stack pointer = 0x28:0xcd3ed9f4
frame pointer = 0x28:0xcd3eda0c
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = resume, IOPL = 0
current process = 1132 (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 0xc10e992b at dtrace_panic+0x1b
#7 0xc10e995d at dtrace_assfail+0x2d
#8 0xc10fb28c at dtrace_probe+0x135c
#9 0xc1237f72 at systrace_probe+0x62
#10 0xc090f63f at syscallenter+0x47f
#11 0xc0c15c14 at syscall+0x34
#12 0xc0bfca11 at Xint0x80_syscall+0x21
Uptime: 3m0s
Physical memory: 239 MB
Dumping 79 MB: 64 48 32 16
Reading symbols from /boot/kernel/dtraceall.ko...
Reading symbols from /boot/kernel/dtraceall.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/dtraceall.ko
Reading symbols from /boot/kernel/cyclic.ko...Reading symbols from
/boot/kernel/cyclic.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/cyclic.ko
Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from
/boot/kernel/opensolaris.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/opensolaris.ko
Reading symbols from /boot/kernel/dtrace.ko...Reading symbols from
/boot/kernel/dtrace.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/dtrace.ko
Reading symbols from /boot/kernel/dtmalloc.ko...Reading symbols from
/boot/kernel/dtmalloc.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/dtmalloc.ko
Reading symbols from /boot/kernel/dtnfsclient.ko...Reading symbols from
/boot/kernel/dtnfsclient.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/dtnfsclient.ko
Reading symbols from /boot/kernel/fbt.ko...Reading symbols from
/boot/kernel/fbt.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/fbt.ko
Reading symbols from /boot/kernel/lockstat.ko...Reading symbols from
/boot/kernel/lockstat.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/lockstat.ko
Reading symbols from /boot/kernel/sdt.ko...Reading symbols from
/boot/kernel/sdt.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/sdt.ko
Reading symbols from /boot/kernel/systrace.ko...Reading symbols from
/boot/kernel/systrace.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/systrace.ko
Reading symbols from /boot/kernel/profile.ko...Reading symbols from
/boot/kernel/profile.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/profile.ko
#0 doadump () at pcpu.h:231
231 __asm("movl %%fs:0,%0" : "=r" (td));
once I'm in the kgdb console i type where and all of a sudden the stack
trace has only 7 frames... that does not seem correct. Furthermore, the
"Previous frame inner to this frame (corrupt stack?)" error message is not
too encuraging either.
(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=0xcd3ed9b4, eva=264) at
/usr/src/sys/i386/i386/trap.c:946
#4 0xc0c15bc0 in trap_pfault (frame=0xcd3ed9b4, usermode=0, eva=264) at
/usr/src/sys/i386/i386/trap.c:859
#5 0xc0c1612a in trap (frame=0xcd3ed9b4) at
/usr/src/sys/i386/i386/trap.c:532
#6 0xc0bfc97c in calltrap () at /usr/src/sys/i386/i386/exception.s:166
#7 0xc11012d7 in dtrace_panic_trigger () from /boot/kernel/dtrace.ko
Previous frame inner to this frame (corrupt stack?)
(kgdb)
what am I doing wrong and what do I have to do to get the specific assert
that fails?
cheers
--m
(sorry adriy hI only hit reply the first time not reply-all)
On Tue, Jul 26, 2011 at 4:05 AM, Andriy Gapon <avg@freebsd.org> wrote:
> on 26/07/2011 04:20 maestro something said the following:
> > Hi,
> >
> > when using the ustack action on the latest FreeBSD8.2 i386 the kernel
> > panics.
> >
> > Here is the information I could gather:
> >
> > let me know if I can provide more information. (i.e., i have the full
> crash
> > information 80+mbs handy)
>
> Use kgdb on the crash dump, go to the dtrace_probe frame and see which
> exactly
> assert fails and why.
>
> > Here is the backtrace:
> >
> > 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:0xc11012d7
> > stack pointer = 0x28:0xcd3ed9f4
> > frame pointer = 0x28:0xcd3eda0c
> > code segment = base 0x0, limit 0xfffff, type 0x1b
> > = DPL 0, pres 1, def32 1, gran 1
> > processor eflags = resume, IOPL = 0
> > current process = 1132 (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 0xc10e992b at dtrace_panic+0x1b
> > #7 0xc10e995d at dtrace_assfail+0x2d
> > #8 0xc10fb28c at dtrace_probe+0x135c
> > #9 0xc1237f72 at systrace_probe+0x62
> > #10 0xc090f63f at syscallenter+0x47f
> > #11 0xc0c15c14 at syscall+0x34
> > #12 0xc0bfca11 at Xint0x80_syscall+0x21
> > Uptime: 3m0s
> > Physical memory: 239 MB
> > Dumping 79 MB: 64 48 32 16
> >
> >
> > Steps To reproduce:
> >
> > the dtrace program (i.e., test.d) was:
> >
> > #!/usr/sbin/dtrace -s
> >
> > syscall::accept:return
> > / execname == "nc" /
> > {
> > printf("%s accept:return\n", execname);
> > ustack();
> > }
> >
> > % dtrace -s test.d
> >
> > then running
> > % nc -vl 8080
> > on one shell and
> > % nc localhost 8080
> > on another would make the kernel panic
>
>
> --
> Andriy Gapon
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ_JOqv5=8Q-7=4YfGu4aKY9duRfhk_Ra4MG_HDs0uoe5_Dg1Q>