From owner-freebsd-stable@FreeBSD.ORG Tue Aug 2 17:46:19 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 11A80106564A; Tue, 2 Aug 2011 17:46:19 +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 900458FC0A; Tue, 2 Aug 2011 17:46:18 +0000 (UTC) Received: by qyk38 with SMTP id 38so4159qyk.13 for ; Tue, 02 Aug 2011 10:46:17 -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=c5ovBfIE9mFuAaMFeQL+B4pSz/glrZ6LlQ40+9UghjI=; b=cfLP7nIzdncWtS2Cuca37F+exK/JME9DeCYHjt08LG3DCZf/2RfrkYI1UOZBvk31ps +x0pJZ4Kb7FymLlsTyL1KG82KSreBB0LCYBlJIuDsL53IQQ5b1vipcJcGvL2tHJDYe60 HzGuOywoa7L6em+2eywxrHGhxvbsCw3nGCOqU= MIME-Version: 1.0 Received: by 10.229.2.68 with SMTP id 4mr1973521qci.174.1312307177684; Tue, 02 Aug 2011 10:46:17 -0700 (PDT) Received: by 10.229.69.218 with HTTP; Tue, 2 Aug 2011 10:46:17 -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: Tue, 2 Aug 2011 10:46:17 -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: Tue, 02 Aug 2011 17:46:19 -0000 Hi, just finished installing FreeBSD-9BETA1 and recompiling the kernel with dtrace. This is even worse, I have the same behavior as mentioned here: http://freebsd.1045724.n5.nabble.com/bin-158431-dtrace-crash-in-dt-proc-lookup-when-attaching-to-PID-assert-dpr-NULL-tt4535367.html#none i.e., dtrace regardless of whether with or without any probes just quits with the following error message Assertion failed: (dpr != NULL), file /usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_proc.c, line 751. that's inside dt_proc_lookup() I think I have to give up on ustack(), too bad cheers --m On Sat, Jul 30, 2011 at 2:05 PM, maestro something wrote: > 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 >