From owner-freebsd-stable@FreeBSD.ORG Sat Jul 30 18:19:41 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 B10B4106566B; Sat, 30 Jul 2011 18:19:41 +0000 (UTC) (envelope-from maestro82@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5DC0F8FC0A; Sat, 30 Jul 2011 18:19:41 +0000 (UTC) Received: by qwc9 with SMTP id 9so3187361qwc.13 for ; Sat, 30 Jul 2011 11:19:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OlZOErIHtZI0iEpwIWUm3m4KLb8YDT4iSgMnoSWEUQs=; b=GYNzk65x8mHn7UNTYTBKPB/lAHjaJ8EJLBUJDwATPA7zQlYOcInWN3oEnGL+QdqifX GS3yFaCfU2miGy71ELY11iIYZvDRU/va+OEtC8xHjBw/CXAqpClNS4bAwo8CxM4d7RkZ G+tF8ofcbrmgi2oMUcWXXxluO1sSp4QBiYW3E= MIME-Version: 1.0 Received: by 10.229.16.200 with SMTP id p8mr2021624qca.22.1312049980584; Sat, 30 Jul 2011 11:19:40 -0700 (PDT) Received: by 10.229.69.218 with HTTP; Sat, 30 Jul 2011 11:19:40 -0700 (PDT) In-Reply-To: <4E33B7CF.90200@FreeBSD.org> References: <4E2E9F60.1060808@FreeBSD.org> <4E33B7CF.90200@FreeBSD.org> Date: Sat, 30 Jul 2011 11:19:40 -0700 Message-ID: From: maestro something To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 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:19:41 -0000 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) How would I do that the in the most straight forward way? > 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). > cheers --m > > > > 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 >