GNOME Bugzilla – Bug 725981
tap-driver.sh: internal error getting exit status
Last modified: 2015-05-11 19:37:49 UTC
I was building glib 2.39.91 on a chroot (as usual) and the test suite failed. No test was reported as FAIL or ERROR in the summaries, but in the middle of the test suite results I found: [...] PASS: defaultvalue 77 /Default Values/GVolumeMonitor PASS: defaultvalue 78 /Default Values/GZlibCompressor PASS: defaultvalue 79 /Default Values/GZlibDecompressor tap-driver.sh: internal error getting exit status tap-driver.sh: fatal: I/O or internal error make[9]: *** [defaultvalue.log] Error 1 PASS: fileattributematcher 1 /fileattributematcher/exact PASS: fileattributematcher 2 /fileattributematcher/equality PASS: fileattributematcher 3 /fileattributematcher/subtract [...] Not sure if this is a bug in the tap driver, or in one of the tests, or elsewhere, or if there was a problem with the build. Other build attempts have built successfully.
This is on a Debian amd64 system running linux 3.13.5 emilio@titan:~$ uname -a Linux titan 3.13-1-amd64 #1 SMP Debian 3.13.5-1 (2014-03-04) x86_64 GNU/Linux
This has also happened on a Debian mipsel autobuilder: PASS: gdbus-proxy 3 /gdbus/proxy/wellknown-noauto PASS: gdbus-proxy 4 /gdbus/proxy/async PASS: gdbus-proxy-threads 1 /gdbus/proxy/vs-threads tap-driver.sh: internal error getting exit status tap-driver.sh: fatal: I/O or internal error make[9]: *** [gdbus-proxy-threads.log] Error 1 PASS: gdbus-proxy-well-known-name 1 /gdbus/proxy-well-known-name PASS: gdbus-test-codegen 1 /gdbus/codegen/annotations https://buildd.debian.org/status/fetch.php?pkg=glib2.0&arch=mipsel&ver=2.39.91-1&stamp=1394394568
(In reply to Emilio Pozuelo Monfort from comment #2) > This has also happened on a Debian mipsel autobuilder: > > PASS: gdbus-proxy 3 /gdbus/proxy/wellknown-noauto > PASS: gdbus-proxy 4 /gdbus/proxy/async > PASS: gdbus-proxy-threads 1 /gdbus/proxy/vs-threads > tap-driver.sh: internal error getting exit status > tap-driver.sh: fatal: I/O or internal error > make[9]: *** [gdbus-proxy-threads.log] Error 1 I've also seen this particular case on Debian x86-64. It's non-deterministic but I think I've fixed it.
Created attachment 303040 [details] [review] GDBus tests: change progress noise from "if not quiet" to "if verbose" It seems that even after Bug #711796, these can still interfere with TAP testing: PASS: gdbus-proxy-threads 1 /gdbus/proxy/vs-threads tap-driver.sh: internal error getting exit status tap-driver.sh: fatal: I/O or internal error Let's shut them up unless --verbose is used (which would be appropriate when running them interactively). Similar symptoms have also been seen in Guix: https://lists.gnu.org/archive/html/bug-guix/2014-12/msg00002.html
I also considered changing all the g_print() in GTest-based tests to g_printerr(), but that's rather a large patch. I think it's worth applying Attachment #303040 [details] first, even if we want to move this noise from stdout to stderr later. (TAP doesn't parse stderr.)
Review of attachment 303040 [details] [review]: Looks good to me. Changing the remaining g_print()s to g_printerr(), or prefixing them with ‘# ’ would be prudent.
Comment on attachment 303040 [details] [review] GDBus tests: change progress noise from "if not quiet" to "if verbose" Pushed as bced30c.
Created attachment 303222 [details] [review] GTestDBus: use g_printerr() for status message This avoids any possibility of interfering with test syntax (such as TAP) on stdout. TAP specifically does not parse stderr.
Created attachment 303223 [details] [review] testglib: my_hash_callback_remove_test: actually fail the test The test is to remove all the odd values with my_hash_callback_remove(), then iterate over all values and verify that they are even. However, failing this check would just print "bad!" instead of failing the test.
Created attachment 303224 [details] [review] GFileMonitor test: use g_test_skip() instead of g_print() This stops it from interfering with structured stdout such as TAP.
Created attachment 303225 [details] [review] tests: replace most g_print() with g_printerr() I searched all files that mention g_test_run, and replaced most g_print() calls. This avoids interfering with TAP. Exceptions: * gio/tests/network-monitor: a manual mode that is run by "./network-monitor --watch" is unaffected * glib/gtester.c: not a test * glib/gtestutils.c: not a test * glib/tests/logging.c: specifically exercising g_print() * glib/tests/markup-parse.c: a manual mode that is run by "./markup-parse --cdata-as-text" is unaffected * glib/tests/testing.c: specifically exercising capture of stdout in subprocesses * glib/tests/utils.c: captures a subprocess's stdout * glib/tests/testglib.c: exercises an assertion failure in g_print()
Review of attachment 303225 [details] [review]: LGTM
(In reply to Simon McVittie from comment #11) > Created attachment 303225 [details] [review] > tests: replace most g_print() with g_printerr() Note that in addition to the listed exceptions in the commit message, the patches in Comment #8, Comment #9, Comment #10 also replace a g_print() that is relevant to this change. They were sufficiently different (not in test code, or in a location where it functionally matters) that I thought they deserved to be their own commit.
Review of attachment 303222 [details] [review]: Yes.
Review of attachment 303223 [details] [review]: From bad to better.
Review of attachment 303224 [details] [review]: Go go gadget commit
Comment on attachment 303222 [details] [review] GTestDBus: use g_printerr() for status message 4865538c, 2.45.2
Comment on attachment 303223 [details] [review] testglib: my_hash_callback_remove_test: actually fail the test 0a9d91ab, 2.45.2
Comment on attachment 303224 [details] [review] GFileMonitor test: use g_test_skip() instead of g_print() 064183a, 2.45.2
Comment on attachment 303225 [details] [review] tests: replace most g_print() with g_printerr() 45dae4b, 2.45.2
Fixed in git for 2.45.2, thanks for the reviews!