On Sat, Jul 30, 2011 at 11:27 AM, Andriy Gapon <a...@freebsd.org> wrote:

> on 30/07/2011 21:19 maestro something said the following:
> >
> >
> > On Sat, Jul 30, 2011 at 12:50 AM, Andriy Gapon <a...@freebsd.org
> > <mailto:a...@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.
>

Looking into that as I type.


>
> >     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.
>

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?

cheers
--m


>
> >
> >     > On Tue, Jul 26, 2011 at 4:05 AM, Andriy Gapon <a...@freebsd.org
> >     <mailto:a...@freebsd.org>
> >     > <mailto:a...@freebsd.org <mailto:a...@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
>
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Reply via email to