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 runtime/17101] [rfe] timeout for stap


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.


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