tinytest uses another way of detecting test failures, it uses pipe
between child and parent, and if the test function in child returns OK
it writes OK flag into pipe, and reads it in parent.
However sanitizers uses atexit handlers to detect leaks, and this will
not detect failures in case of exit() will be called from the atexit
handlers, fix this by checking status after waitpid().
We have some tests that has false-positive due to real/CPU time bound,
but they are pretty generic and we do not want to skip them by default.
TT_RETRIABLE is the flag that will indicate tinytest to retry the test
in case of failure, use it to avoid next possible false-positives:
- real time-related
- CPU time-related
Since I guess it is better to see/grepping RETRYING messages over
ignoring completely failed builds.
No configuration switch for number of retries was done on purpose (only
3 retries and no more).
And this is how it looks BTW:
$ gcc ../test/tinytest_demo.c ../test/tinytest.c
$ ./a.out --verbose --no-fork
demo/timeout_retry
demo/timeout_retry:
FAIL ../test/tinytest_demo.c:201: assert(i != 1): 1 vs 1
[timeout_retry FAILED]
[RETRYING timeout_retry (3)]
demo/timeout_retry:
OK ../test/tinytest_demo.c:201: assert(i != 1): 2 vs 1
OK ../test/tinytest_demo.c:213: assert(t2-t1 >= 4): 5 vs 4
OK ../test/tinytest_demo.c:215: assert(t2-t1 <= 6): 5 vs 6
1 tests ok. (0 skipped)
Some of our unit tests and sample code need functions and structures
defined in an -internal.h header. But that can freak out OpenSolaris,
where stdio.h wants to define _FILE_OFFSET_BITS unless it's already
defined, and then evconfig-internal.h defines it. Regular users
should never ever use our -internal.h headers, so the solution is
to make sure that if we're going to use them ourselves, we do so
before system headers.
Original post:
This post is in response to a posting last December on a Windows
regression fork failure ([Libevent-users] Re: Libevent 2.0.10-stable
is released by Dongsheng Song). I noticed the question was not
answered and I recently experienced the same error myself when
trying to run the Windows regression tests myself.
I checked the return status from the CreateProcess call and found it
was "file not found". This led me to look at the command-line I was
using which was .\regress in a Visual Studio 2008 command prompt
window. Windows could not find the file because it did not have the
.exe extension on the end. The code that builds the command should
be modified to ensure the extension is present.
The big win here is that we can get process-level isolation.
This has been tested to work okay on at least Linux and Win32. Only
the tests in regress.c have been converted wrapped in the new wrapper
functions; the others are still on the old system.
svn:r1073