From owner-freebsd-stable@FreeBSD.ORG Tue Aug 2 18:34:31 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 8B43D106564A; Tue, 2 Aug 2011 18:34:31 +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 2D0818FC0A; Tue, 2 Aug 2011 18:34:30 +0000 (UTC) Received: by qwc9 with SMTP id 9so48564qwc.13 for ; Tue, 02 Aug 2011 11:34:30 -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=60A+cFrSsV4TxFwqFrazNj59C/6U8lL19w19t29iD0Y=; b=pjMW0+UlaV0YMv5TcCVXBBtSv8rVIwzp4OjzkRR+ZKYM+NHZOQ7zQIYZs3iGRB6dn0 y7xk2TAUkaAVlPp+qICwiYzmH4AgNTOZWj/TeukvnMkcvnVnbIHqTBETkfJACa9+GdPH L32iXJ3FcAQ8Aw55pDeMcASKgwG3zntOTwfmQ= MIME-Version: 1.0 Received: by 10.229.2.68 with SMTP id 4mr2013050qci.174.1312310070250; Tue, 02 Aug 2011 11:34:30 -0700 (PDT) Received: by 10.229.69.218 with HTTP; Tue, 2 Aug 2011 11:34:30 -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 11:34:30 -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 18:34:31 -0000 Hi, 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 this is not accurate. It seems that this message only occurs if i use the ustack() action. i.e, dtrace -n 'syscall::accept:return /execname == "nc" / { printf("%s accept:return\n", execname);}' works as expected However, dtrace -n 'syscall::accept:return /execname == "nc" / { printf("%s accept:return\n", execname);ustack();}' does not: it results in the mentioned error message. Assertion failed: (dpr != NULL), file /usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_proc.c, line 751. cheers --m > > > 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 >> > >