public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: "mcermak at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: systemtap@sourceware.org
Subject: [Bug runtime/17101] [rfe] timeout for stap
Date: Wed, 09 Jul 2014 17:49:00 -0000	[thread overview]
Message-ID: <bug-17101-6586-iVJFye3GHC@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-17101-6586@http.sourceware.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.

  parent reply	other threads:[~2014-07-09 17:49 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-30 13:51 [Bug runtime/17101] New: " mcermak at redhat dot com
2014-06-30 14:22 ` [Bug runtime/17101] " dsmith at redhat dot com
2014-06-30 16:34 ` fche at redhat dot com
2014-07-01  7:00 ` mcermak at redhat dot com
2014-07-03 18:45 ` fche at redhat dot com
2014-07-04 11:30 ` mcermak at redhat dot com
2014-07-04 14:26 ` fche at redhat dot com
2014-07-07 13:21 ` mcermak at redhat dot com
2014-07-07 15:39 ` dsmith at redhat dot com
2014-07-07 16:32 ` jistone at redhat dot com
2014-07-09 17:49 ` mcermak at redhat dot com [this message]
2014-07-15 19:50 ` ajakop at redhat dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-17101-6586-iVJFye3GHC@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=systemtap@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).