This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug testsuite/17864] New: alias_tapset.exp regressed
- From: "mcermak at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Wed, 21 Jan 2015 14:34:40 +0000
- Subject: [Bug testsuite/17864] New: alias_tapset.exp regressed
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=17864
Bug ID: 17864
Summary: alias_tapset.exp regressed
Product: systemtap
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: testsuite
Assignee: systemtap at sourceware dot org
Reporter: mcermak at redhat dot com
Compared to latest rhel7 systemtap-2.6-8.el7, the latest upstream version
d6fa7e4 of alias_tapset.exp now always fails on s390x (which has a clear
reason) and sometimes fails on other arches too (I'm not sure why yet).
On s390 the failure is obviously caused by commit befbf100. The testcase needs
to be adapted to expect not only 'SyS_read', but also 'sys32_read'. This part
is easy.
Now first of all the output of `stap -p2` got significantly more verbose with
newer stap. The original output (expected by the testcase) was something like:
=======
# globals
_reads:long
# probes
never /* <- tapset_test.foo = never <- tapset_test.foo */
kernel.function("SyS_read@fs/read_write.c:492").call /* pc=_stext+0x17cb78 */
/* <- kernel.function("SyS_read@fs/read_write.c:492").call */
timer.s(5) /* <- timer.s(5) */
=======
Now, with stap based on d6fa7e4, the output has way more details, But the
expected pattern still seems to be at the end, which is good.
Problem is, that during my testing I see the expected pattern only when running
`stap -p2 -I ./systemtap.base/alias_tapset ./systemtap.base/alias_tapset.stp`
by hand. But when this gets run within the dejagnu testcase, the expected
pattern is not there. When Investigating the problem I modified the testcase
like this:
=======
$ git diff
diff --git a/testsuite/systemtap.base/alias_tapset.exp
b/testsuite/systemtap.base/alias_tapset.exp
index 82b1420..7be0153 100644
--- a/testsuite/systemtap.base/alias_tapset.exp
+++ b/testsuite/systemtap.base/alias_tapset.exp
@@ -8,7 +8,9 @@ set kernel_function_found 0
set timer_found 0
set cmd "stap -p2 -I $srcdir/$subdir/${test} $srcdir/$subdir/${test}.stp"
+set cmd1 "stap -p2 -I $srcdir/$subdir/${test} $srcdir/$subdir/${test}.stp >
/tmp/log"
verbose -log "running $cmd"
+eval exec $cmd1
eval spawn $cmd
expect {
-timeout 60
$
=======
Then tail of systemtap log is:
=======
/* (old) PTRACE requests with inverted arguments */
#ifndef PPC_PTRACE_GETREGS
#define PPC_PTRACE_GETREGS 0x99
#endif
#ifndef PPC_PTRACE_SETREGS
#define PPC_PTRACE_SETREGS 0x98
#endif
#ifndef PPC_PTRACE_GETFPREGFAIL: alias_tapset (0, 0, 0, 0)
testcase ./systemtap.base/alias_tapset.exp completed in 3 seconds
=== systemtap Summary ===
# of unexpected failures 1
runtest completed at Wed Jan 21 08:10:17 2015
=======
(the expected bits are missing here ^ ) whereas tail of /tmp/log is:
=======
/* (old) PTRACE requests with inverted arguments */
#ifndef PPC_PTRACE_GETREGS
#define PPC_PTRACE_GETREGS 0x99
#endif
#ifndef PPC_PTRACE_SETREGS
#define PPC_PTRACE_SETREGS 0x98
#endif
#ifndef PPC_PTRACE_GETFPREGS
#define PPC_PTRACE_GETFPREGS 0x97
#endif
#ifndef PPC_PTRACE_SETFPREGS
#define PPC_PTRACE_SETFPREGS 0x96
#endif
%}
# globals
_reads:long
# functions
error:unknown (msg:string)
# probes
never /* <- tapset_test.foo = never <- tapset_test.foo */
timer.s(900) /* <- timer.s(900) */
kernel.function("SyS_read@fs/read_write.c:492").call /* pc=_stext+0x2d6520 */
/* <- kernel.function("SyS_read@fs/read_write.c:492").call */
timer.s(5) /* <- timer.s(5) */
=======
(expected bits are in place). Something goes wrong when `stap -p2 -I
./systemtap.base/alias_tapset ./systemtap.base/alias_tapset.stp` gets called
within the dejagnu testcase. I can reproduce this reliably on el7.1 ppc64.
--
You are receiving this mail because:
You are the assignee for the bug.