dtrace ustack kernel panic

[maestro something]

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 at 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
>