From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22417 invoked by alias); 25 Dec 2011 11:07:40 -0000 Received: (qmail 22404 invoked by uid 22791); 25 Dec 2011 11:07:39 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,TW_CV X-Spam-Check-By: sourceware.org Received: from xvm-20-226.ghst.net (HELO fruli.krunch.be) (92.243.20.226) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 25 Dec 2011 11:07:22 +0000 Received: from localhost (localhost [127.0.0.1]) by fruli.krunch.be (Postfix) with ESMTP id 5C653227F7; Sun, 25 Dec 2011 11:04:39 +0000 (UTC) Date: Sun, 25 Dec 2011 20:20:00 -0000 From: Adrien Kunysz To: Josh Stone Cc: contemplating zombie , systemtap@sourceware.org Subject: Re: Puzzling output of stp script Message-ID: <20111225110952.GD17069@chouffe> References: <4EF6BAEB.7000006@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0lnxQi9hkpPO77W3" Content-Disposition: inline In-Reply-To: <4EF6BAEB.7000006@redhat.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2011-q4/txt/msg00425.txt.bz2 --0lnxQi9hkpPO77W3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2012 On Sat, Dec 24, 2011 at 09:55:55PM -0800, Josh Stone wrote: > On 12/24/2011 10:31 AM, contemplating zombie wrote: > > Hi, > >=20 > > I am new to systemtap and I was trying out following example script > > given in the documentation: > >=20 > > probe kernel.function("*@net/socket.c") { > > printf ("%s -> %s\n", thread_indent(1), probefunc()) > > } > >=20 > > probe kernel.function("*@net/socket.c").return { > > printf ("%s <- %s\n", thread_indent(-1), probefunc()) > > } > >=20 > > 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? >=20 > 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. >=20 > 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. >=20 > 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=3Dsystemtap.git;a=3Dcommitdiff;h=3D3= 96afcee5ada2d207b7a6691d4b7ce473e7b2a65 > > 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 >=20 > 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. --0lnxQi9hkpPO77W3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline Content-length: 198 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk73BIAACgkQKLX03ZSPZGyPfQCfTk3dtL/O2OshwQbwYxaCCcGI ikYAn3hj/RPoZAm+UjPKm55mlMxYTmaC =/zw5 -----END PGP SIGNATURE----- --0lnxQi9hkpPO77W3--