From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2227 invoked by alias); 29 Apr 2009 12:08:42 -0000 Received: (qmail 2217 invoked by uid 22791); 29 Apr 2009 12:08:40 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_74,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 29 Apr 2009 12:08:33 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n3TC8SJ8003094; Wed, 29 Apr 2009 08:08:28 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n3TC8R1a011369; Wed, 29 Apr 2009 08:08:27 -0400 Received: from [10.32.10.142] (vpn-10-142.str.redhat.com [10.32.10.142]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n3TC8O1R020588; Wed, 29 Apr 2009 08:08:26 -0400 Subject: Re: Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2 From: Mark Wielaard To: ananth@in.ibm.com Cc: systemtap@sourceware.org In-Reply-To: <20090429092634.GA3411@in.ibm.com> References: <1240843370.4387.45.camel@fedora.wildebeest.org> <20090428065617.GD1531@in.ibm.com> <1240995422.2389.2.camel@fedora.wildebeest.org> <20090429092634.GA3411@in.ibm.com> Content-Type: text/plain Date: Wed, 29 Apr 2009 12:08:00 -0000 Message-Id: <1241006903.4267.11.camel@fedora.wildebeest.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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: 2009-q2/txt/msg00473.txt.bz2 Hi Ananth, On Wed, 2009-04-29 at 14:56 +0530, Ananth N Mavinakayanahalli wrote: > On Wed, Apr 29, 2009 at 10:57:01AM +0200, Mark Wielaard wrote: > > > > Yes, that seems fine. The LOCAL1 (0) failure case is as you observed > > because of the syscall wrappers issue (I am thinking about the patch you > > proposed in PR10007 and testing it locally - x86_64 only for now > > though). > > Thanks Mark. I've attached an updated version just now. So that patch does give some new failures for me (version 0.9.7/0.137 commit release-0.9.7-27-g9997403 + changes on 2.6.18-128.1.6.el5xen x86_64): attempting command stap -p4 para-callgraph.stp kernel.function("*@fs/proc*.c") syscall.read OUT semantic error: probe point mismatch at position 2 (alternatives: return): identifier 'syscall' at para-callgraph.stp:15:7 while resolving probe point syscall.read.call source: probe $2.call { ^ Pass 2: analysis failed. Try again with another '--vp 01' option. child process exited abnormally RC 1 FAIL: systemtap.examples/general/para-callgraph build So the problem there is that the function probe can have a .call attribute, but the syscall probe doesn't. spawn1 stap -p4 /home/mark/src/systemtap/testsuite/buildok/maxactive01.stp semantic error: probe point mismatch at position 3 (alternatives:): identifier 'syscall' at /home/mark/src/systemtap/testsuite/buildok/maxactive01.stp:3:7 while resolving probe point syscall.read.return.maxactive(3) semantic error: probe point mismatch at position 3 (alternatives:): identifier 'syscall' at /home/mark/src/systemtap/testsuite/buildok/maxactive01.stp:3:7 while resolving probe point syscall.read.return.maxactive(3) source: probe syscall.read.return.maxactive(3) source: probe syscall.read.return.maxactive(3) ^ ^ semantic error: no probes found semantic error: no probes found Pass 2: analysis failed. Try again with another '--vp 01' option.^M Pass 2: analysis failed. Try again with another '--vp 01' option.^M wait results: 16579 exp33 0 1 FAIL: buildok/maxactive01.stp Similar problem, but now that a function.return probe can have a maxactive attribute, while a syscall.return probe cannot. The rest does seem to PASS as before, but I am somewhat concerned that the tests were originally designed to test function (.call/return) probes, which are different from syscall (.return) probes. So are we really still testing the correct things? Cheers, Mark