What is wrong with dtrace's stack()?

[Alan Somers]

On Sun, Oct 21, 2018 at 3:38 PM Lev Serebryakov <lev at freebsd.org> wrote:

> Hello Conrad,
>
> Sunday, October 21, 2018, 8:21:43 PM, you wrote:
>
> > Your assembler dump offsets are in decimal.  Look for offset 0x33 =
> > +51, not +33.
>  Problem is, sosend() is not very interesting by itself, and looks like
> several layers of stack are always lost.
>
>  I see a lot of stacks like this:
>
>  kernel`lock_delay+0x42
>  kernel`soo_write+0x33
>  kernel`dofilewrite+0x79
>  kernel`sys_write+0xc3
>  kernel`amd64_syscall+0x332
>  kernel`0xffffffff8086c87d
>
>  But event sosend() doesn't call lock_delay(), so it is impossible to
> understand why do lock_delay() seen 41932 times in 60 seconds at top of the
> stack. Where are all call stack?! All these functions could not be inlined,
> as sosend() is located in other translation unit and it calls function by
> pointer, this call could not be inlined too.
>

If you're sure that the function isn't inlined, then it might be using the
tail-call optimization instead.  That would also explain the missing stack
frames, too.  If you can manually narrow the options down to a few possible
callers, then you could try adding a few SDT probes.  That's what I usually
do in cases like this.  Or, for static functions that are inlined, you can
remove the static keyword to (usually) prevent the inlining.
-Alan


>
>
> --
> Best regards,
>  Lev                            mailto:lev at FreeBSD.org
>
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>