search

dtr-org / unit-e

A digital currency for a new era of decentralized trust
https://unit-e.io
MIT License
45 stars 15 forks source link

Fix unit test: util_tests_datadir/test_LockDirectory #1049

Closed scravy closed 5 years ago

scravy commented 5 years ago

On macOS the following call:

src/test/test_unite --run_test=util_tests_datadir/test_LockDirectory

Fails:

Running 1 test case...
libc++abi.dylib: terminating with uncaught exception of type std::__1::system_error: mutex lock failed: Invalid argument
test/util_tests.cpp:1342: error: in "util_tests_datadir/test_LockDirectory": check processstatus == 0 has failed [11 != 0]

*** 1 failure is detected in the test module "Unit-e Test Suite"

The test itself fails as the BOOST_CHECK which checks that the child process terminated correctly is trigger (as the child does not terminate correctly). The unit test actually forks (sic!) the process. The forked process actually works fine too and only blows up on calling exit.

This pull request changes the call to exit to _Exit. _Exit is available on Linux as well as on bsd systems (so macOS, freeBSD etc should work). It is already excluded from windows builds, as windows does not support fork.

_Exit does not call the destructors of statically allocated variables, nor any functions registered using atexit (we do not have any functions registered using atexit anyhow).

This fix makes the test pass as the test is not broken, but there seems to be an order-of-initialization-and-destruction with some static variables which is not fixed by this "fix". Then again it only shows in this particular test when forking the process and during shutdown. It does not happen during any functional test apparently and has not been seen to happen in any other scenario.

Signed-off-by: Julian Fleischer julian@thirdhash.com

frolosofsky commented 5 years ago

From man _exit (which _Exit is an alias to):

The function _exit() is like exit(3), but does not call any functions registered with atexit(3) or on_exit(3). Whether it flushes standard I/O buffers and removes temporary files created with tmpfile(3) is implementation-dependent. On the other hand, _exit() does close open file descriptors, and this may cause an unknown delay, waiting for pending output to finish. If the delay is undesired, it may be useful to call functions like tcflush(3) before calling _exit(). Whether any pending I/O is canceled, and which pending I/O may be canceled upon _exit(), is implementation-dependent.

Maybe disable that test completely for now?

scravy commented 5 years ago

I do not see a problem with what you cited. It's only used to exit the forked child process.