Date: Tue, 2 Aug 2011 11:34:30 -0700 From: maestro something <maestro82@gmail.com> To: Kostik Belousov <kostikbel@gmail.com> Cc: freebsd-stable@freebsd.org, Andriy Gapon <avg@freebsd.org> Subject: Re: dtrace ustack kernel panic Message-ID: <CAJ_JOqvkRAOcZay5KCJPULaKPaJC8g4gffpac9O-Zr84rOV4BA@mail.gmail.com> In-Reply-To: <CAJ_JOqsWNDeh_2SW5cz1PDewALJoANhuW81d4TjxWSK1w=nAjw@mail.gmail.com> References: <CAJ_JOqvEmXBTBABhUcJ66=bh9%2B8S%2BC9v30hXxVZiCXuEpGPJ1A@mail.gmail.com> <4E2E9F60.1060808@FreeBSD.org> <CAJ_JOqszViwLi6TeQxAxeX2Mte5eBPsGJpjQPVOQs2BOwAq9JQ@mail.gmail.com> <4E33B7CF.90200@FreeBSD.org> <CAJ_JOqt4VdgJm3NnB1KUf1RFuk75nu6-Rh=Bqb53h5TAEzB0%2BA@mail.gmail.com> <4E344D15.1040508@FreeBSD.org> <CAJ_JOqvCDE1Zcv4jz14rtZu5_NmqfY04tz91uy76WnaW2trO7Q@mail.gmail.com> <CAJ_JOqu2SR2n1Cm__3x3rfcJpYY=ihnoE9oyuKeNmKGuUGgnGA@mail.gmail.com> <20110730192646.GC17489@deviant.kiev.zoral.com.ua> <CAJ_JOqtofEjt-jiZBiLKW--fY0sdiHvF36baS3Qxc8ubmQMazg@mail.gmail.com> <CAJ_JOqtsrOr7Uq0Jo-Mb8kKnucjUarJxKrgzNEbMxTcGP7OCAw@mail.gmail.com> <CAJ_JOqsWNDeh_2SW5cz1PDewALJoANhuW81d4TjxWSK1w=nAjw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <maestro82@gmail.com>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 >> > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ_JOqvkRAOcZay5KCJPULaKPaJC8g4gffpac9O-Zr84rOV4BA>