Re: Puzzling output of stp script

[Adrien Kunysz <adrien@kunysz.be>]

[-- Attachment #1: Type: text/plain, Size: 2035 bytes --]

On Sat, Dec 24, 2011 at 09:55:55PM -0800, Josh Stone wrote:
> 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).

And that particular example was already fixed a while ago btw:
http://sourceware.org/git/gitweb.cgi?p=systemtap.git;a=commitdiff;h=396afcee5ada2d207b7a6691d4b7ce473e7b2a65

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]