test-node-exponential: timeout expired. failing.
The Debian package build fails lately like below on mipsel and mips64el.
...
./test-node-exponential
timeout expired. failing.
FAIL test-node-exponential
...
=== Test Results ===
tests passed: 30
tests skipped: 1
tests failed: 1
====== FAIL ======
This is downstream tracked in Debian Bug 940190.
Increasing the timeout from 3 seconds to 40 makes the build succeed at least in my very slow qemu VM.
But I am not sure if this is what the test should reveal. So I guess the question is: Is it safe to increase that timeout?
--- orig/gegl-0.4.12/tests/simple/test-node-exponential.c 2018-07-12 00:15:19.000000000 +0200
+++ try1/gegl-0.4.12/tests/simple/test-node-exponential.c 2019-09-14 05:58:25.992956588 +0200
@@ -37,7 +37,7 @@
#define SUCCESS 0
#define FAILURE -1
-#define TIMEOUT (3 * G_TIME_SPAN_SECOND)
+#define TIMEOUT (40 * G_TIME_SPAN_SECOND)
static GMutex mutex;
static GCond cond;
After putting some logging g_print ("%s:%d:\n", __FUNCTION__, __LINE__);
to the test it seems that the expensive call is gegl_node_get_input_proxy
.
benutzer@debian:~/source/gegl/try2/gegl-0.4.14/tests/simple$ time ./test-node-exponential | ts '[%Y-%m-%d %H:%M:%.S]'
[2019-09-15 18:47:58.758131] main:100: begin
[2019-09-15 18:48:15.125223] main:103: after gegl_init
[2019-09-15 18:48:15.132181] main:108: after g_get_monotonic_time
[2019-09-15 18:48:15.136965] main:111: after g_mutex_lock
[2019-09-15 18:48:15.151574] test:54: begin
[2019-09-15 18:48:15.164651] test:57: after gegl_node_new
[2019-09-15 18:48:27.175821] test:61: after gegl_node_get_input_proxy
[2019-09-15 18:48:27.333091] test:78: after loop
[2019-09-15 18:48:27.365328] test:86: after finished = TRUE
[2019-09-15 18:48:27.370865] test:91: end
[2019-09-15 18:48:27.382286] main:124: after g_thread_join
[2019-09-15 18:48:27.421475] main:127: end
real 0m31.332s
user 0m30.623s
sys 0m0.551s