Puzzling output of stp script

[Josh Stone]

On 12/24/2011 10:31 AM, contemplating zombie wrote:
> Hi,
> 
> I am new to systemtap and I was trying out following example script
> given in the documentation:
> 
> probe kernel.function("*@net/socket.c") {
>       printf ("%s -> %s\n", thread_indent(1), probefunc())
> }
> 
> probe kernel.function("*@net/socket.c").return {
>       printf ("%s <- %s\n", thread_indent(-1), probefunc())
> }
> 
> I sshed into a remote machine and executed it. What I see is that the
> stack frames just keep on growing to right and do not return. Won't
> that cause a stack overflow eventually?

The reason is that you are probing more functions on entry than you are
on return.  There's no stack issue; the probes are just imbalanced.

There are two flavors of entry probe: .call and .inline.  If you don't
specify, then you get a union of both.  However, .return probes only
work for the .call flavor, because there is no real return from inlined
functions.

So when you need balanced probes for entering and leaving functions, use
.call and .return.  You could also be clever and represent the .inline
separately with thread_indent(0).

>      0 sshd(804): -> sock_poll
>     11 sshd(804): <- sock_poll
>      0 sshd(804): -> sock_aio_read
>      2 sshd(804):  -> alloc_sock_iocb
>      3 sshd(804):  <- alloc_sock_iocb
>      5 sshd(804):  -> do_sock_read
>      7 sshd(804):   -> __sock_recvmsg
>      9 sshd(804):    -> __sock_recvmsg_nosec
>     15 sshd(804):    <- sock_aio_read

Notice right here, you got a return from sock_aio_read, jumping back
over three other "calls".  I'll bet that do_sock_read, __sock_recvmsg,
and __sock_recvmsg_nosec were all inlined in your kernel.