It seems that the tests suffer from some kind of race condition when run in parallel which causes them to fail randomly. I've been able to reproduce it with even '-j2', in less than 10 attempts using the following bash command line: $ for x in {1..10}; do dbus-launch make -j2 check || break; done The failing tests are: make[4]: Entering directory '/home/mgorny/git/xfconf/tests/property-changed-signal' FAIL: t-string-changed-signal PASS: t-string-changed-signal-detailed ============================================================================ Testsuite summary for xfconf 4.13.4git-6c276ef ============================================================================ # TOTAL: 2 # PASS: 1 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 ============================================================================ See tests/property-changed-signal/test-suite.log Please report to http://bugzilla.xfce.org/ ============================================================================ make[4]: *** [Makefile:759: test-suite.log] Error 1 (either one or the other fails) The test-suite.log is not very helpful: FAIL: t-string-changed-signal ============================= FAIL t-string-changed-signal (exit status: 1) I think you should be able to reproduce it (may need more attempts). If you can't, please let me know how we can help.
I can confirm the "bug". We can't run some tests in parallel with other tests (I think that's why we have a g_timeout_add(2000 the code). I propose to add .NOPARALLEL: inside tests/property-changed-signal/Makefile.am to force this xfconf tests to not run in parallel. This fix the problem for me. https://www.gnu.org/software/make/manual/make.html#Parallel
When you run the loop test, do you end up having many xfconfd instances running?
By running the loop with dbus-launch make like OP, yes, I end up with many xfconfd instances running. By removing dbus-launch, I only have one xfconfd instance, but the bug still occurs.