This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug testsuite/19639] New: parallel_exec.exp fails in beaker-project.org
- From: "mcermak at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Mon, 15 Feb 2016 16:41:05 +0000
- Subject: [Bug testsuite/19639] New: parallel_exec.exp fails in beaker-project.org
- Auto-submitted: auto-generated
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.