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 <maestr...@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 > _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
