From owner-freebsd-stable@FreeBSD.ORG Sat Jul 30 18:27:38 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 880F0106564A for ; Sat, 30 Jul 2011 18:27:38 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E709C8FC0C for ; Sat, 30 Jul 2011 18:27:37 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA29154; Sat, 30 Jul 2011 21:27:35 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QnEG7-0008Jc-Cs; Sat, 30 Jul 2011 21:27:35 +0300 Message-ID: <4E344D15.1040508@FreeBSD.org> Date: Sat, 30 Jul 2011 21:27:33 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: maestro something References: <4E2E9F60.1060808@FreeBSD.org> <4E33B7CF.90200@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: dtrace ustack kernel panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2011 18:27:38 -0000 on 30/07/2011 21:19 maestro something said the following: > > > On Sat, Jul 30, 2011 at 12:50 AM, Andriy Gapon > 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 > > >> 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