As noted in #12843, we’re currently missing bugs unique to bitcoin-qt during the Travis build because the functional test framework only uses bitcoind (and not bitcoin-qt).
Run a single Travis job under xvfb for framebuffer virtualization and using bitcoin-qt as the binary. I’ve also removed the NEED_XVFB configuration since our usage of xvfb is outdated per Travis’ docs and the corresponding pre-build step is no longer necessary.
61@@ -61,7 +62,6 @@ before_script:
62 - if [ -n "$OSX_SDK" -a -f depends/sdk-sources/MacOSX${OSX_SDK}.sdk.tar.gz ]; then tar -C depends/SDKs -xf depends/sdk-sources/MacOSX${OSX_SDK}.sdk.tar.gz; fi
63 - if [ -z "$NO_DEPENDS" ]; then make $MAKEJOBS -C depends HOST=$HOST $DEP_OPTS; fi
64 # Start xvfb if needed, as documented at https://docs.travis-ci.com/user/gui-and-headless-browsers/#Using-xvfb-to-Run-Tests-That-Require-a-GUI
Concept ACK b42a408783b345d3f6c46e26a2d24dd00e1cff70
Seems one test is failing due to #12863.
For the actual bitcoin-qt job failing I tried to reproduce errors locally with Xvfd, manually setting BITCOIND to bitcoin-qt, but had no luck (all tests pass).
@conscott thanks for trying to reproduce locally. I’ve been doing same and while I’m unable to reproduce on my 16.04 host, I’ve been able to reproduce reliably on a 14.04 VM.
I think running the functional suite using the qt binary has uncovered a latent deadlock, perhaps due to 14.04’s older default version of OpenSSL (1.0.1f) based on a tip from @TheBlueMatt.
Here’s some relevant log output from the tests:
0stderr:
1bitcoin-qt: sync.cpp:101: void potential_deadlock_detected(const std::pair<void*, void*>&, const LockStack&, const LockStack&): Assertion `false' failed.
2...
3node0 2018-04-17T23:41:37.857938Z GUI: PaymentServer::LoadRootCAs: Loaded 145 root certificates
4node0 2018-04-17T23:41:38.262348Z POTENTIAL DEADLOCK DETECTED
5node0 2018-04-17T23:41:38.262376Z Previous lock order was:
6node0 2018-04-17T23:41:38.262386Z (1) ppmutexOpenSSL[i] util.cpp:107
7node0 2018-04-17T23:41:38.262403Z (2) cs ./addrman.h:508
8node0 2018-04-17T23:41:38.262416Z Current lock order is:
9node0 2018-04-17T23:41:38.262424Z (2) cs ./addrman.h:473
10node0 2018-04-17T23:41:38.262437Z (1) ppmutexOpenSSL[i] util.cpp:107
I’m going to continue to investigate.
82@@ -83,6 +83,7 @@ def __init__(self):
83 self.setup_clean_chain = False
84 self.nodes = []
85 self.mocktime = 0
86+ self.binary = os.getenv("BITCOIND", "bitcoind")
In particular, skip any assert_start_raises_init_error checks due to the way
QT handles startup errors (presents the user with an error dialog which must be
closed). In the future we may implement a better way of handling this.
As noted in https://github.com/bitcoin/bitcoin/pull/12843, we're currently
missing bugs unique to bitcoin-qt during the Travis build because the
functional test framework only uses bitcoind (and not bitcoin-qt).
Run a single Travis job under xvfb for framebuffer virtualization and using
bitcoin-qt as the binary. Remove outdated NEED_XVFB Travis configuration.
79@@ -74,7 +80,11 @@ script:
80 - DOCKER_EXEC make $MAKEJOBS $GOAL || ( echo "Build failure. Verbose build follows." && DOCKER_EXEC make $GOAL V=1 ; false )
81 - if [ "$RUN_TESTS" = "true" ]; then DOCKER_EXEC LD_LIBRARY_PATH=$TRAVIS_BUILD_DIR/depends/$HOST/lib make $MAKEJOBS check VERBOSE=1; fi
82 - if [ "$TRAVIS_EVENT_TYPE" = "cron" ]; then extended="--extended --exclude feature_pruning,feature_dbcrash"; fi
83- - if [ "$RUN_TESTS" = "true" ]; then DOCKER_EXEC test/functional/test_runner.py --combinedlogslen=4000 --coverage --quiet --failfast ${extended}; fi
84+ - if [ "$RUN_TESTS_WITH_QT" = "true" ]; then
85+ DOCKER_EXEC BITCOIND=$(DOCKER_EXEC find . -name 'bitcoin-qt' -executable) $FUNCTIONAL_TEST_CMD ${extended};
BITCOIND=bitcoin-qt and it will look in the build dir automatically, as opposed to ./, what your find does.