This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug runtime/17101] [rfe] timeout for stap
- From: "mcermak at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Wed, 09 Jul 2014 17:48:54 +0000
- Subject: [Bug runtime/17101] [rfe] timeout for stap
- Auto-submitted: auto-generated
- References: <bug-17101-6586 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=17101
--- Comment #10 from Martin Cermak <mcermak at redhat dot com> ---
(In reply to David Smith from comment #8)
> Martin, are there certain tests in the testsuite where you have the most
> problems with missing timeout behavior?
So for example th FJ testsuite runs following testcase which "hangs" on
el6.x86_64:
# cat DWARF_probes_004.stp
probe kernel.function("sys_read").return.maxactive(5) {
printf("%s\n", probefunc())
exit()
}
Other such example from the same testsuite which "hangs on el7.x86_64 is:
# cat probe_definition_003_ext4.stp
probe module("ext4").function("ext4_*") {
printf("%s\n", probefunc())
exit()
}
Similarly testcases relying capably on the open syscall will hang on aarch64,
since it has opent instead.
-------
When running any testsuite in an automated way, it is frustrating to work with
such situations, although they're easily solvable by hand when one has an easy
access on a testing box. Getting such hang in an automated testing framework
means that no results from testcases following the hangy one are obtained.
Provosioning a box takes time as well as running the testsuite. For this reason
I'd appreciate this functionality. If we know of testcases that wouldn't fail
appropriately due to this, then I'd propose to fix them so that that clearly
fail if the timeout is hit.
--
You are receiving this mail because:
You are the assignee for the bug.