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"
