This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2


On Wed, Apr 29, 2009 at 02:08:23PM +0200, Mark Wielaard wrote:
> 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.

Ugh yes :(

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

Maybe the choice of functions weren't correct in the first place? Why
don't we change this to say, vfs_read instead of sys_read?

Ananth


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]