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