From owner-freebsd-stable@FreeBSD.ORG Sat Jul 30 18:30:28 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 7A82E106564A; Sat, 30 Jul 2011 18:30:28 +0000 (UTC) (envelope-from maestro82@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1E3208FC12; Sat, 30 Jul 2011 18:30:27 +0000 (UTC) Received: by qyk38 with SMTP id 38so3178314qyk.13 for ; Sat, 30 Jul 2011 11:30:27 -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=DegtesGDB7hLCcbBYcsELBgoRnH9TQfhntwuo2mpGtk=; b=jEBoVLokC9bq3+xq6wZf0cVSobBWHcowYGmz8iPf7kcEKNvvel5n6I+8Kb4hpVHgjg BkO/wgAJwnzrYmP2YZueM6LHgRWix79NB+/4DRQSfVgIrCTABl0U8r6+eXldiamlKIuF mvGSr5UMFYKvKjrUSM4yeZbmm3fbUxweyFOxk= MIME-Version: 1.0 Received: by 10.229.215.202 with SMTP id hf10mr2033587qcb.212.1312050627193; Sat, 30 Jul 2011 11:30:27 -0700 (PDT) Received: by 10.229.69.218 with HTTP; Sat, 30 Jul 2011 11:30:27 -0700 (PDT) In-Reply-To: <4E344D15.1040508@FreeBSD.org> References: <4E2E9F60.1060808@FreeBSD.org> <4E33B7CF.90200@FreeBSD.org> <4E344D15.1040508@FreeBSD.org> Date: Sat, 30 Jul 2011 11:30:27 -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:30:28 -0000 On Sat, Jul 30, 2011 at 11:27 AM, Andriy Gapon wrote: > 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. > 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 > > > > >> 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 >