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]

[Bug testsuite/19639] New: parallel_exec.exp fails in beaker-project.org


https://sourceware.org/bugzilla/show_bug.cgi?id=19639

            Bug ID: 19639
           Summary: parallel_exec.exp fails in beaker-project.org
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: testsuite
          Assignee: systemtap at sourceware dot org
          Reporter: mcermak at redhat dot com
  Target Milestone: ---

The parallel_exec.exp always fails when run in the beaker-project.org testing
framework. When run by hand, it seems to always pass.

The testcase uses Tcl's spawn() to measure the count of open and close
syscalls, but exec() to get a reference value:

> set num [exec stap -e "$script" -c "cat /etc/hosts > /dev/null" | grep {\(open\|close\)} | wc -l]

versus

> spawn stap -e "$script" -c "cat /etc/hosts > /dev/null"
> ... count opens and closes in the output ...

These values do not match in beaker. 

The print_ubacktrace() shows that in case of exec() there is an extra 'open'
syscall coming from glibc (0x7fa13a1627e0
[/usr/lib64/libc-2.17.so+0xe77e0/0x3c1000]) compared to spawn(). Originally I
thought it's because of the pipes, but now I don't think so. However, I must
admit that I'm not sure about the root cause.

Sidenote: Beaker by default uses "beah" test harness, which requires a new test
box provisioning for new test case run. Which is not a worktime-wise way of
repetitive reproducing the issue. But now I succeeded replicating the issue (or
at least something very similar) using an alternative restraint harness which
allows to run a testcase repeatedly on already provisioned testing box
(http://restraint.readthedocs.org/en/latest/using.html#running-standalone).

So, what seems to work the issue around for me is either wrapping all the piped
commands into `sh -c '...'` (grep 'open\|close'` is redundant anyway), or - and
that looks better to me - to acquire both values using the same mechanism, e.g.
using spawn():

=======
# git diff
diff --git a/testsuite/systemtap.stress/parallel_exec.exp
b/testsuite/systemtap.stress/parallel_exec.exp
index f0e221f..f039d89 100644
--- a/testsuite/systemtap.stress/parallel_exec.exp
+++ b/testsuite/systemtap.stress/parallel_exec.exp
@@ -21,7 +21,16 @@ set script {
 #
 # Note that executing this here preloads the cache with the script for
 # the stap invocations in the loop below.
-set num [exec stap -e "$script" -c "cat /etc/hosts > /dev/null" | grep
{\(open\|close\)} | wc -l]
+set num 0
+spawn stap -e "$script" -c "cat /etc/hosts > /dev/null"
+expect {
+    -timeout 60
+    -re {^(open|close)\r\n} {
+        incr num
+        exp_continue
+    }
+}
+catch {close}; catch {wait}

 set spawn_ids {}
 for { set i 0 } { $i < $process_num } { incr i } {
=======

Too many words for pretty much nothing. I am sorry :)

-- 
You are receiving this mail because:
You are the assignee for the bug.

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