RE: Recent test results

RE: Recent test results

[Keshavamurthy, Anil S]

Martin,
	Can you mail your fix so I can verify the same on my Ia64 box.

-thanks,
Anil 

>-----Original Message-----
>From: systemtap-owner@sourceware.org 
>[mailto:systemtap-owner@sourceware.org] On Behalf Of Martin Hunt
>Sent: Friday, November 11, 2005 12:36 PM
>To: William Cohen
>Cc: systemtap@sources.redhat.com
>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
>
>
>
>

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: systemtap-owner@sourceware.org 
>>[mailto:systemtap-owner@sourceware.org] On Behalf Of Martin Hunt
>>Sent: Friday, November 11, 2005 12:36 PM
>>To: William Cohen
>>Cc: systemtap@sources.redhat.com
>>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
>>
>>
>>
>>

RE: Recent test results

[Martin Hunt]

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

Re: Recent test results

[Keshavamurthy Anil S]

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

RE: Recent test results

[Keshavamurthy, Anil S]

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; systemtap@sources.redhat.com
>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: systemtap-owner@sourceware.org 
>[mailto:systemtap-owner@sourceware.org]
>>On Behalf Of Martin Hunt
>>Sent: 2005年11月12日 4:53
>>To: Keshavamurthy, Anil S
>>Cc: William Cohen; systemtap@sources.redhat.com
>>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
>>
>
>

RE: Recent test results

[Mao, Bibo]

[-- Attachment #1: Type: text/plain, Size: 1836 bytes --]

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: systemtap-owner@sourceware.org [mailto:systemtap-owner@sourceware.org]
>On Behalf Of Martin Hunt
>Sent: 2005年11月12日 4:53
>To: Keshavamurthy, Anil S
>Cc: William Cohen; systemtap@sources.redhat.com
>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
>


[-- Attachment #2: patch_stap_run --]
[-- Type: application/octet-stream, Size: 706 bytes --]

--- orig/lib/stap_run.exp	2005-09-03 06:34:12.000000000 +0800
+++ runtest/lib/stap_run.exp	2005-11-14 03:21:55.000000000 +0800
@@ -42,6 +42,16 @@
 	    expect {
 		-re  $output {
 		    pass "$test shutdown and output"
+		
+		    set output "^systemtap unload module successfully\n$"
+		    expect {
+			-re $output{
+				pass "$test unload module"
+				close
+			}
+			timeout {fail "$test unload module (timeout)"}
+			eof { fail "$test unload module (eof)"}	
+		    }			
 		}
 		timeout { fail "$test shutdown (timeout)" }
 		eof { fail "$test shutdown (eof)" }
@@ -51,6 +61,7 @@
 	timeout { fail "$test startup (timeout)" }
 	eof { fail "$test startup (eof)" }
     }
+    wait
 }
 
 proc no_load {} {

[-- Attachment #3: patch_librelay --]
[-- Type: application/octet-stream, Size: 281 bytes --]

--- systemtap-20051112.orig/runtime/stpd/librelay.c	2005-10-20 03:35:35.000000000 +0800
+++ systemtap-20051112/runtime/stpd/librelay.c	2005-11-14 03:03:31.000000000 +0800
@@ -631,6 +631,7 @@
 			exit(1);
 		}
 	}
+	printf("systemtap unload module successfully\n");
 	exit(0);
 }
 

Re: Recent test results

[Martin Hunt]

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

Re: Recent test results

[William Cohen]

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

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

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: