From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18368 invoked by alias); 25 Dec 2011 05:56:18 -0000 Received: (qmail 18359 invoked by uid 22791); 25 Dec 2011 05:56:17 -0000 X-SWARE-Spam-Status: No, hits=-7.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_CV X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 25 Dec 2011 05:55:57 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBP5tt0c013631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 25 Dec 2011 00:55:55 -0500 Received: from [10.3.113.6] ([10.3.113.6]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id pBP5ttmg005103; Sun, 25 Dec 2011 00:55:55 -0500 Message-ID: <4EF6BAEB.7000006@redhat.com> Date: Sun, 25 Dec 2011 11:07:00 -0000 From: Josh Stone User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: contemplating zombie CC: systemtap@sourceware.org Subject: Re: Puzzling output of stp script References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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/msg00424.txt.bz2 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.