Let's try to actually handle the server unexpectedly alive
case by first making them visible on CI builds as failures.
This is needed to detect issues with killing of the test
servers completely including nested process chains with
multiple PIDs per test server (including bash and perl).
On Windows/cygwin platforms this is especially helpful with
debugging PID mixups due to cygwin using its own PID space.
Reviewed-by: Daniel Stenberg
Closes#7180
To make it easier to write ranges like '115 to 229' without that
explicitly enabling tests that are listed in DISABLED, this makes
runtests always skip disabled tests unless the -f command line option is
used.
Previously the code attempted to not run such tests, but didn't do it
correctly.
Closes#7212
Introduce a new runtests.pl command option: -rm
For now only required and implemented for Windows.
Ignore stunnel logs due to long running processes.
Requires Sysinternals handle[64].exe to be on PATH.
Reviewed-by: Jay Satiro
Ref: #6058Closes#6179
When using randomized features of runtests (-R and --shallow) it is
useful to have a fixed random seed to make sure for example extra
commits in a branch or a rebase won't change the seed that would make
repeated runs work differently.
As it is also useful to change seed sometimes, the default seed is now
determined based on the current month (and first line curl -V
output). When the month changes, so will the random seed.
The specific seed is also shown in the standard test suite top header
and it can be set explictly with the new --seed=[num] option so that the
exact order of a previous run can be achieved.
Closes#4734
When set, shallow mode limits runtests -t to make no more than NUM fails
per test case. If more are found, it will randomly discard entries until
the number is right. The random seed can also be set.
This is particularly useful when running MANY tests as then most torture
failures will already fail the same functions over and over and make the
total operation painfully tedious.
Closes#4699
The specified curl binary will then be used to verify the running
server(s) instead of the development version. This is very useful in
some cases when the development version fails to verify correctly as
then the test case may not run at all.
The actual test will still be run with the "normal" curl executable
(unless the test case specifies something differently).
This function is meant to work *exactly* as curl_easy_perform() but will
use the event-based libcurl API internally instead of
curl_multi_perform(). To avoid relying on an actual event-based library
and to not use non-portable functions (like epoll or similar), there's a
rather inefficient emulation layer implemented on top of Curl_poll()
instead.
There's currently some convenience logging done in curl_easy_perform_ev
which helps when tracking down problems. They may be suitable to remove
or change once things seem to be fine enough.
curl has a new --test-event option when built with debug enabled that
then uses curl_easy_perform_ev() instead of curl_easy_perform(). If
built without debug, using --test-event will only output a warning
message.
NOTE: curl_easy_perform_ev() is not part if the public API on purpose.
It is only present in debug builds of libcurl and MUST NOT be considered
stable even then. Use it for libcurl-testing purposes only.
runtests.pl now features an -e command line option that makes it use
--test-event for all curl command line tests. The man page is updated.
