Date: Sat, 30 Jul 2011 21:27:33 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: maestro something <maestro82@gmail.com> Cc: freebsd-stable@FreeBSD.org Subject: Re: dtrace ustack kernel panic Message-ID: <4E344D15.1040508@FreeBSD.org> In-Reply-To: <CAJ_JOqt4VdgJm3NnB1KUf1RFuk75nu6-Rh=Bqb53h5TAEzB0%2BA@mail.gmail.com> References: <CAJ_JOqvEmXBTBABhUcJ66=bh9%2B8S%2BC9v30hXxVZiCXuEpGPJ1A@mail.gmail.com> <4E2E9F60.1060808@FreeBSD.org> <CAJ_JOqszViwLi6TeQxAxeX2Mte5eBPsGJpjQPVOQs2BOwAq9JQ@mail.gmail.com> <4E33B7CF.90200@FreeBSD.org> <CAJ_JOqt4VdgJm3NnB1KUf1RFuk75nu6-Rh=Bqb53h5TAEzB0%2BA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
on 30/07/2011 21:19 maestro something said the following:
>
>
> On Sat, Jul 30, 2011 at 12:50 AM, Andriy Gapon <avg@freebsd.org
> <mailto:avg@freebsd.org>> wrote:
>
> on 30/07/2011 00:27 maestro something said the following:
> > 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.
> >
> [snip]
> > kernel trap 12 with interrupts disabled
> >
>
> I am not quite sure. Apparently there is some issue with either what
> information we store in a crash dump and how, or with how kgdb interprets that
> information, or with a combination of both...
> Perhaps this is a result of -O2 optimization and -O1 would improve the situation
>
>
> I guess I have to recompile the kernel without -O then ... does that work for
> freebsd (I remember linux has issues i.e., does not compile without any -O)
Not sure about -O0; -O1/-O should work fine.
> How would I do that the in the most straight forward way?
See man make.conf: CFLAGS, etc.
> Meanwhile, there is something simple that you can do without much hassle:
> (kgdb) list *dtrace_probe+0x135c
>
>
> True there was not a lot hassle involved. However the result is not really
> satisfactory either :-)
>
> (kgdb) list *dtrace_probe+0x135c
> No source file for address 0xc10fb28c.
>
> The address is in accordance with the stack-trace (i.e., frame #8)
>
>
> where the address is taken from the backtrace printed by panic(9).
Have you started kgdb with the correct kernel and core file?
If yes, then I am out of ideas.
>
> > On Tue, Jul 26, 2011 at 4:05 AM, Andriy Gapon <avg@freebsd.org
> <mailto:avg@freebsd.org>
> > <mailto:avg@freebsd.org <mailto: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
>
>
--
Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E344D15.1040508>