While investigating golang/go#36664, the entire output of a failure
could get pretty long - past fifty lines of content. I was getting
confused as to why the output was being cut off.
I had to discard a number of theories (the test being buggy, my expected
output being wrong, etc) before I realised that something was truncating
the output for the sake of the reader.
Since that's what stress is doing, make it add an ellipsis character
too, to further hint to the user that the output is being truncated for
readability. Separate it with a newline to make it easier to notice.
Change-Id: Ie052c13bb48d6fd842d6054848161266d9ea17e6
Reviewed-on: https://go-review.googlesource.com/c/tools/+/215597
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Currently, stress logs are named "/tmp/go-stress-" plus a random
number. This makes it really annoying to tease apart failures from
different stress runs.
This CL changes the default prefix to
"/tmp/go-stress-<ISO 8601 date/time>-<random number>"
where the date/time part is when the stress command started. This
naming clusters logs by stress invocation, making it easy to tease
apart invocations, even if there are multiple stresses running
concurrently or they are run back-to-back.
This also provides a flag to override this prefix.
Change-Id: I043e5ee7168ba6db4e2355e39b147071edbc6864
Reviewed-on: https://go-review.googlesource.com/c/150047
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Provide more context when you run `stress -h` besides just the flags.
Change-Id: I9dbe7ba2b7178dd7a542d8c4c29bf79999a38234
Reviewed-on: https://go-review.googlesource.com/44810
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This adds a flag for specifying a regular expression for failures that
should be ignored. This is useful for filtering out known issues and
provides a logical mirror to the existing -failure flag.
Change-Id: Ibbacdd2125aa23fe819896e5a17664b703c4ee35
Reviewed-on: https://go-review.googlesource.com/12676
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Currently at the end of a long stress run you may not know from the
end of the output whether there were any failures. Add a failure count
to the periodic status message to make this obvious.
Change-Id: I5ad19b9e6f462369fb32be6efbfb6f21568e98e4
Reviewed-on: https://go-review.googlesource.com/10187
Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
The stress utility is intended for catching of episodic failures.
It runs a given process in parallel in a loop and collects any failures.
Usage:
$ stress ./fmt.test -test.run=TestSometing -test.cpu=10
You can also specify a number of parallel processes with -p flag;
instruct the utility to not kill hanged processes for gdb attach;
or specify the failure output you are looking for (if you want to
ignore some other episodic failures).
Do you find it useful?
I use it for several years for all kinds of episodic failures (not just Go btw).
Change-Id: I06553345b76768a819412acb45f9bdfb3bababf7
Reviewed-on: https://go-review.googlesource.com/9373
Reviewed-by: Keith Randall <khr@golang.org>
