Recent test results

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Recent test results

William Cohen
Tried out testing a current snapshot of systemtap (20051111) on some
systems.


The pfaults.exp times out because the test runs for too long on the
various i386 platforms, e.g.  RHEL4-U2, FC4 and i386 rawhide. Assuming
that there is a direct correspondence between jiffies and number of
seconds looks like a bad assumption. Jiffies per second vary between
distributions and architectures. on i386 machines 250 jiffies/second
would cause the search for the completion of the test to take 40
seconds, longer than the 30 seconds allowed.

revised pfaults to run for successfully for anything that has 100 or
more jiffies per second.

Looking into why some of the x86_64 tests start failing when all are
run. It looks like it is failing in the same way as the ia64 tests
that Anil ran earlier in the week; things go wrong with simple.exp.
Also noticed that x86_64 version failed to report the systemtap
version.

-Will



i386 FC4
                 === systemtap Summary ===

# of expected passes            107

kernel version: 2.6.13-1.1532_FC4
systemtap translator version: version 0.4.2 built 2005-11-11


i386 rawhide
                 === systemtap Summary ===

# of expected passes            107

kernel version: 2.6.14-1.1656_FC5smp
systemtap translator version: version 0.4.2 built 2005-11-11

i386 RHEL4-U2

reboots spontaneously when testing ./systemtap.samples/profile.exp
(BZ 1808 entered for it, might be the same as BZ 1345)

x86_64 RHEL4-U2

FAIL: ./systemtap.base/simple.stp startup (timeout)
FAIL: ./systemtap.base/subtract.stp startup (timeout)
FAIL: ./systemtap.base/tri.stp startup (timeout)
FAIL: ./systemtap.base/xor.stp startup (timeout)
FAIL: arith
FAIL: arith
FAIL: control_limits MAXNESTING (0)
FAIL: control_limits MAXACTION (0)
FAIL: control_limits MAXSTRINGLEN small (0)
FAIL: control_limits MAXSTRINGLEN large (0)
FAIL: pfaults (0)
FAIL: primes
FAIL: profile
FAIL: symbols (0)
FAIL: syscalls-count (0)
FAIL: syscalls-run (0)
FAIL: sysopen (0)
FAIL: transport normal - procfs (0)
FAIL: transport normal - relayfs (0)
FAIL: transport fill staging buffer - procfs (0)
FAIL: transport fill staging buffer - relayfs (0)
                 === systemtap Summary ===

# of expected passes            79
# of unexpected failures        21

kernel version: 2.6.9-22.0.1.ELsmp
WARNING: systemtap_version failed:
Reply | Threaded
Open this post in threaded view
|

Re: Recent test results

Martin Hunt
On Fri, 2005-11-11 at 14:35 -0500, William Cohen wrote:
> Tried out testing a current snapshot of systemtap (20051111) on some
> systems.
[...]
> Looking into why some of the x86_64 tests start failing when all are
> run. It looks like it is failing in the same way as the ia64 tests
> that Anil ran earlier in the week; things go wrong with simple.exp.
> Also noticed that x86_64 version failed to report the systemtap
> version.
I got the same results as you.

I'm certainly not an expect expert, but a quick look at stap_run.exp
shows a major flaw. I made a quick fix and now I get:

Running ./systemtap.samples/syscalls2.exp ...
Running ./systemtap.samples/sysopen.exp ...
Running ./systemtap.samples/transport.exp ...

                === systemtap Summary ===

# of expected passes            107

kernel version: 2.6.9-22.0.1.ELsmp
systemtap translator version: version 0.4.2 built 2005-11-11



Reply | Threaded
Open this post in threaded view
|

RE: Recent test results

Keshavamurthy, Anil S
In reply to this post by William Cohen
Martin,
        Can you mail your fix so I can verify the same on my Ia64 box.

-thanks,
Anil

>-----Original Message-----
>From: [hidden email]
>[mailto:[hidden email]] On Behalf Of Martin Hunt
>Sent: Friday, November 11, 2005 12:36 PM
>To: William Cohen
>Cc: [hidden email]
>Subject: Re: Recent test results
>
>On Fri, 2005-11-11 at 14:35 -0500, William Cohen wrote:
>> Tried out testing a current snapshot of systemtap (20051111) on some
>> systems.
>[...]
>> Looking into why some of the x86_64 tests start failing when all are
>> run. It looks like it is failing in the same way as the ia64 tests
>> that Anil ran earlier in the week; things go wrong with simple.exp.
>> Also noticed that x86_64 version failed to report the systemtap
>> version.
>I got the same results as you.
>
>I'm certainly not an expect expert, but a quick look at stap_run.exp
>shows a major flaw. I made a quick fix and now I get:
>
>Running ./systemtap.samples/syscalls2.exp ...
>Running ./systemtap.samples/sysopen.exp ...
>Running ./systemtap.samples/transport.exp ...
>
>                === systemtap Summary ===
>
># of expected passes            107
>
>kernel version: 2.6.9-22.0.1.ELsmp
>systemtap translator version: version 0.4.2 built 2005-11-11
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Recent test results

William Cohen
Keshavamurthy, Anil S wrote:
> Martin,
> Can you mail your fix so I can verify the same on my Ia64 box.

It is already checked into the cvs, so you should be able to do an "cvs
update -d -P" to get it.

-Will

>
> -thanks,
> Anil
>
>
>>-----Original Message-----
>>From: [hidden email]
>>[mailto:[hidden email]] On Behalf Of Martin Hunt
>>Sent: Friday, November 11, 2005 12:36 PM
>>To: William Cohen
>>Cc: [hidden email]
>>Subject: Re: Recent test results
>>
>>On Fri, 2005-11-11 at 14:35 -0500, William Cohen wrote:
>>
>>>Tried out testing a current snapshot of systemtap (20051111) on some
>>>systems.
>>
>>[...]
>>
>>>Looking into why some of the x86_64 tests start failing when all are
>>>run. It looks like it is failing in the same way as the ia64 tests
>>>that Anil ran earlier in the week; things go wrong with simple.exp.
>>>Also noticed that x86_64 version failed to report the systemtap
>>>version.
>>
>>I got the same results as you.
>>
>>I'm certainly not an expect expert, but a quick look at stap_run.exp
>>shows a major flaw. I made a quick fix and now I get:
>>
>>Running ./systemtap.samples/syscalls2.exp ...
>>Running ./systemtap.samples/sysopen.exp ...
>>Running ./systemtap.samples/transport.exp ...
>>
>>               === systemtap Summary ===
>>
>># of expected passes            107
>>
>>kernel version: 2.6.9-22.0.1.ELsmp
>>systemtap translator version: version 0.4.2 built 2005-11-11
>>
>>
>>
>>

Reply | Threaded
Open this post in threaded view
|

RE: Recent test results

Martin Hunt
In reply to this post by Keshavamurthy, Anil S
On Fri, 2005-11-11 at 12:49 -0800, Keshavamurthy, Anil S wrote:
> Martin,
> Can you mail your fix so I can verify the same on my Ia64 box.
>
> -thanks,
> Anil

Index: testsuite/lib/stap_run.exp
===================================================================
RCS file: /cvs/systemtap/tests/testsuite/lib/stap_run.exp,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- testsuite/lib/stap_run.exp  2 Sep 2005 22:34:12 -0000       1.5
+++ testsuite/lib/stap_run.exp  11 Nov 2005 20:37:47 -0000      1.6
@@ -51,6 +51,8 @@
        timeout { fail "$test startup (timeout)" }
        eof { fail "$test startup (eof)" }
     }
+  close
+  wait
 }

 proc no_load {} {

--------

It's checked into CVS.

Martin


Reply | Threaded
Open this post in threaded view
|

Re: Recent test results

William Cohen
In reply to this post by Martin Hunt
Martin Hunt wrote:

> On Fri, 2005-11-11 at 14:35 -0500, William Cohen wrote:
>
>>Tried out testing a current snapshot of systemtap (20051111) on some
>>systems.
>
> [...]
>
>>Looking into why some of the x86_64 tests start failing when all are
>>run. It looks like it is failing in the same way as the ia64 tests
>>that Anil ran earlier in the week; things go wrong with simple.exp.
>>Also noticed that x86_64 version failed to report the systemtap
>>version.
>
> I got the same results as you.
>
> I'm certainly not an expect expert, but a quick look at stap_run.exp
> shows a major flaw. I made a quick fix and now I get:
>
> Running ./systemtap.samples/syscalls2.exp ...
> Running ./systemtap.samples/sysopen.exp ...
> Running ./systemtap.samples/transport.exp ...
>
>                 === systemtap Summary ===
>
> # of expected passes            107
>
> kernel version: 2.6.9-22.0.1.ELsmp
> systemtap translator version: version 0.4.2 built 2005-11-11
>
>
>

Thanks, Martin.

I am wondering if there are similar close operations missing in test run
later in the sequence.


-Will
Reply | Threaded
Open this post in threaded view
|

Re: Recent test results

Keshavamurthy, Anil S
In reply to this post by William Cohen
On Fri, Nov 11, 2005 at 03:51:37PM -0500, William Cohen wrote:
> Keshavamurthy, Anil S wrote:
> > Martin,
> > Can you mail your fix so I can verify the same on my Ia64 box.
>
> It is already checked into the cvs, so you should be able to do an "cvs
> update -d -P" to get it.
Hi Martin and Will,
        Thanks a lot, timeout issues on Ia64 is now resolved.
Here is the test output on Ia64.

[..]
Running ./systemtap.samples/syscalls1.exp ...
FAIL: syscalls-count (236)
Running ./systemtap.samples/syscalls2.exp ...
FAIL: syscalls-run (1001)
Running ./systemtap.samples/sysopen.exp ...
FAIL: sysopen (0)
Running ./systemtap.samples/transport.exp ...

                ===  Summary ===

# of expected passes            104
# of unexpected failures        3
----------------------------------------
Now I see only 3 tests failing, I will investigate it.

Thanks again,
Anil


Reply | Threaded
Open this post in threaded view
|

Re: Recent test results

Martin Hunt
In reply to this post by William Cohen
On Fri, 2005-11-11 at 15:53 -0500, William Cohen wrote:
>
> Thanks, Martin.
>
> I am wondering if there are similar close operations missing in test run
> later in the sequence.

Probably, but they only cause problems if you do too many spawns in a
loop and forget to close and wait.

Martin


Reply | Threaded
Open this post in threaded view
|

RE: Recent test results

bibo,mao-2
In reply to this post by William Cohen
Yes, after add close and wait sentence in stap_run.exp. There will be no timeout information. But after "runtest" command, if we use lsmod command, there will be some module that is not uninstalled named stapxxx.

Maybe it is because of spawn process is closed before it unload stap module. We can print some information when rmmod in file librelay.c. And then expect this information in stap_run.exp script, and at last after unload module, we can close this process.

By the way stap_fun.exp function is only called by runtest script in systemtap.base directory, and in systemtap.samples directory it is not. Maybe we add wait sentence in each runtest exp script in systemtap.samples directory.

The attachment is patch for librelay.c and stap_run.exp.

>-----Original Message-----
>From: [hidden email] [mailto:[hidden email]]
>On Behalf Of Martin Hunt
>Sent: 2005年11月12日 4:53
>To: Keshavamurthy, Anil S
>Cc: William Cohen; [hidden email]
>Subject: RE: Recent test results
>
>On Fri, 2005-11-11 at 12:49 -0800, Keshavamurthy, Anil S wrote:
>> Martin,
>> Can you mail your fix so I can verify the same on my Ia64 box.
>>
>> -thanks,
>> Anil
>
>Index: testsuite/lib/stap_run.exp
>===================================================================
>RCS file: /cvs/systemtap/tests/testsuite/lib/stap_run.exp,v
>retrieving revision 1.5
>retrieving revision 1.6
>diff -u -r1.5 -r1.6
>--- testsuite/lib/stap_run.exp  2 Sep 2005 22:34:12 -0000       1.5
>+++ testsuite/lib/stap_run.exp  11 Nov 2005 20:37:47 -0000      1.6
>@@ -51,6 +51,8 @@
>        timeout { fail "$test startup (timeout)" }
>        eof { fail "$test startup (eof)" }
>     }
>+  close
>+  wait
> }
>
> proc no_load {} {
>
>--------
>
>It's checked into CVS.
>
>Martin
>


patch_stap_run (970 bytes) Download Attachment
patch_librelay (386 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

dejagnu spawn & wait

Frank Ch. Eigler
Hi -

Indeed, the "close;wait" is not a perfect solution to the zombie stap
problem.  Systemtap catches SIGINT to cause an early exit, not
SIGTERM/SIGPIPE/etc, so dejagnu should send a SIGINT and wait a while
before the "close;wait".

By the way, I'm somewhat surprised that the zombie stap processes
should cause anything but an aesthetic problem.  They should consume
no resources except perhaps dejagnu file descriptors.

- FChE
Reply | Threaded
Open this post in threaded view
|

Re: dejagnu spawn & wait

Roland McGrath
It should probably catch SIGTERM as well.  People expect "kill %1 RET" to kill
it cleanly similarly to "fg RET ^C".
Reply | Threaded
Open this post in threaded view
|

RE: Recent test results

Keshavamurthy, Anil S
In reply to this post by William Cohen
Bibo,
        Adding printf() in librelay.c file is wrong thing. For example when a scrip is run say
"./my_test.stp" and then a CTRL+C, users will see your printf("systemtap unload module successful")
which is a wrong thing as user is not expected to see any thing other than what is described in their script.

Rejecting your patch.

-Anil Keshavamurthy

>-----Original Message-----
>From: Mao, Bibo
>Sent: Sunday, November 13, 2005 7:42 PM
>To: 'Martin Hunt'; Keshavamurthy, Anil S
>Cc: William Cohen; [hidden email]
>Subject: RE: Recent test results
>
>Yes, after add close and wait sentence in stap_run.exp. There
>will be no timeout information. But after "runtest" command,
>if we use lsmod command, there will be some module that is not
>uninstalled named stapxxx.
>
>Maybe it is because of spawn process is closed before it
>unload stap module. We can print some information when rmmod
>in file librelay.c. And then expect this information in
>stap_run.exp script, and at last after unload module, we can
>close this process.
>
>By the way stap_fun.exp function is only called by runtest
>script in systemtap.base directory, and in systemtap.samples
>directory it is not. Maybe we add wait sentence in each
>runtest exp script in systemtap.samples directory.
>
>The attachment is patch for librelay.c and stap_run.exp.
>
>>-----Original Message-----
>>From: [hidden email]
>[mailto:[hidden email]]
>>On Behalf Of Martin Hunt
>>Sent: 2005年11月12日 4:53
>>To: Keshavamurthy, Anil S
>>Cc: William Cohen; [hidden email]
>>Subject: RE: Recent test results
>>
>>On Fri, 2005-11-11 at 12:49 -0800, Keshavamurthy, Anil S wrote:
>>> Martin,
>>> Can you mail your fix so I can verify the same on my Ia64 box.
>>>
>>> -thanks,
>>> Anil
>>
>>Index: testsuite/lib/stap_run.exp
>>===================================================================
>>RCS file: /cvs/systemtap/tests/testsuite/lib/stap_run.exp,v
>>retrieving revision 1.5
>>retrieving revision 1.6
>>diff -u -r1.5 -r1.6
>>--- testsuite/lib/stap_run.exp  2 Sep 2005 22:34:12 -0000       1.5
>>+++ testsuite/lib/stap_run.exp  11 Nov 2005 20:37:47 -0000      1.6
>>@@ -51,6 +51,8 @@
>>        timeout { fail "$test startup (timeout)" }
>>        eof { fail "$test startup (eof)" }
>>     }
>>+  close
>>+  wait
>> }
>>
>> proc no_load {} {
>>
>>--------
>>
>>It's checked into CVS.
>>
>>Martin
>>
>
>