This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug runtime/17101] [rfe] timeout for stap
- From: "jistone at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Mon, 07 Jul 2014 16:32:42 +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
Josh Stone <jistone at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jistone at redhat dot com
--- Comment #9 from Josh Stone <jistone at redhat dot com> ---
(In reply to Frank Ch. Eigler from comment #6)
> just teach stap to accept multiple -e SCRIPT bits
Using multiple -e is fine, but script files are chosen as the first non-option
argument. So how do we decide between (-e SCRIPT_TEXT SCRIPT_FILE ARG...) and
(-e SCRIPT_TEXT ARG...) ?
I thought perhaps just testing the file-existence of the first argument, but I
often use things like 'process(@1).mark("*")'. So then you'd have to have some
heuristic to decide that it's not just a file, but a real script too.
I suggest adding a new argument flag for these supplementary script pieces.
Perhaps simply -E, and users will still be required to have a primary -e or
script file. A -E can also be ignored by non-script modes, -l, --dump, etc.
(In reply to David Smith from comment #8)
> Hmm, I wonder if this rc file modification will work exactly the way we'd
> like. I could see where the testcase would just ignore the new output and
> not fail properly.
We need to fix such tests whenever we find them. I've found several cases of
bugs that were displayed in testcases, but were masked because one good line of
output made it report success. In one test, I even saw that the *absence* of a
particular error message was counted as success, but a different error was
preventing it from getting to the point of interest at all.
--
You are receiving this mail because:
You are the assignee for the bug.