Date: Tue, 2 Aug 2011 10:46:17 -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_JOqsWNDeh_2SW5cz1PDewALJoANhuW81d4TjxWSK1w=nAjw@mail.gmail.com> In-Reply-To: <CAJ_JOqtsrOr7Uq0Jo-Mb8kKnucjUarJxKrgzNEbMxTcGP7OCAw@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <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_JOqsWNDeh_2SW5cz1PDewALJoANhuW81d4TjxWSK1w=nAjw>