From owner-freebsd-stable@FreeBSD.ORG Sat Jul 30 21:05:34 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 45BDE106566B; Sat, 30 Jul 2011 21:05:34 +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 DC8908FC13; Sat, 30 Jul 2011 21:05:33 +0000 (UTC) Received: by qyk38 with SMTP id 38so3215163qyk.13 for ; Sat, 30 Jul 2011 14:05:33 -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=sgHsQ8EOkhwgBTLgJ+Z+2sIMceQO/lMQOaY2FbPOTXg=; b=PCv9l98ii2jgMoiLHpbSW/WeagVXwta+kFKUxZZIaB6AeI6lPbXC25JoMnqY9qlQaa Bq9X29TweAwMOYJOG0Q1lq5xCKUcRMMHltfQuJEx8UKmB9VoLBeAa7sbnjLuLRLsOC2N gtuuETltHHE4etNvXROBnDR5DOPjdQhmUib0E= MIME-Version: 1.0 Received: by 10.229.22.20 with SMTP id l20mr2110875qcb.60.1312059933184; Sat, 30 Jul 2011 14:05:33 -0700 (PDT) Received: by 10.229.69.218 with HTTP; Sat, 30 Jul 2011 14:05:33 -0700 (PDT) In-Reply-To: References: <4E2E9F60.1060808@FreeBSD.org> <4E33B7CF.90200@FreeBSD.org> <4E344D15.1040508@FreeBSD.org> <20110730192646.GC17489@deviant.kiev.zoral.com.ua> Date: Sat, 30 Jul 2011 14:05:33 -0700 Message-ID: From: maestro something To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org, Andriy Gapon 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 21:05:34 -0000 Hi, > This is i386, right ? >> I think the cause is that assembler routine panic_trigger does not >> establish the standard i386 frame. Basically, you need either this, >> or dwarf annotations, for gdb to be able to walk over the frame. >> >> You need to add the standard prologue >> pushl %ebp >> movl %esp,%ebp >> and standard epilogue >> leave >> to the function. No idea whether it will continue to operate correctly >> after. >> > > my panic_trigger looks like this now: > > /* > int > panic_trigger(int *tp) > */ > ENTRY(panic_trigger) > > pushl %ebp > movl %esp,%ebp > xorl %eax, %eax > movl $0xdefacedd, %edx > lock > xchgl %edx, (%edi) > cmpl $0, %edx > je 0f > movl $0, %eax > leave > ret > 0: movl $1, %eax > leave > ret > END(panic_trigger) > > same result, (actually too same as the address in the stack trace is still > the same, is that possible?) > > 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 0xc10e99db at dtrace_panic+0x1b #7 0xc10e9a0d at dtrace_assfail+0x2d #8 0xc10fa6a6 at dtrace_probe+0xfd6 #9 0xc1237ce4 at systrace_probe+0x84 #10 0xc090f63f at syscallenter+0x47f #11 0xc0c15c14 at syscall+0x34 #12 0xc0bfca11 at Xint0x80_syscall+0x21 I tried playing around with kgdb a bit. It finds source files until frame #10 (i.e., syscallenter + 0x47f) (kgdb) list *syscallenter+0x47f 0xc090f63f is in syscallenter (/usr/src/sys/kern/subr_trap.c:328). 323 * If the systrace module has registered it's probe 324 * callback and if there is a probe active for the 325 * syscall 'return', process the probe. 326 */ 327 if (systrace_probe_func != NULL && sa->callp->sy_return != 0) 328 (*systrace_probe_func)(sa->callp->sy_return, sa->code, 329 sa->callp, sa->args); 330 #endif 331 CTR4(KTR_SYSC, "syscall: p=%p error=%d return %#lx %#lx", 332 p, error, td->td_retval[0], td->td_retval[1]); (kgdb) list *systrace_probe+0x84 No source file for address 0xc1237ce4. Thus, it seems that the first frame where kgdb cannot find a source file is #9 (i.e., systrace_probe + 0x84) As far as I understand that's when the (imho) function pointer systrace_probe_func gets invoked. Therefore, it seems that kgdb has a hard time finding the source file for the function invoked through that pointer. Is this complete nonsense, or does that actually sound familiar to anyone? And still I'm wondering whether anybody ever successfully used the ustack action on Freebsd-8.2 i386 cheers --m