Open debalance opened 1 month ago
Looking at one of the test log files, the error message is
In my test machine I was able to make that testcase fail by decreasing CALL_TIMEOUT in eimp_worker:
diff --git a/src/eimp_worker.erl b/src/eimp_worker.erl
index 17e1e2a..48945fc 100644
--- a/src/eimp_worker.erl
+++ b/src/eimp_worker.erl
@@ -27,7 +27,7 @@
terminate/2, code_change/3]).
-define(MAX_RETRIES, 2).
--define(CALL_TIMEOUT, 30000).
+-define(CALL_TIMEOUT, 100).
-record(state, {port :: undefined | port(),
links = sets:new() :: sets:set(),
However, in my case the error message does not look identical:
Let's hope the differences in the error message are related to the Erlang-EUnit version (I used Erlang 26.3 and 27.1), or the test environment...
I managed to reproduce the error in an armel chroot on https://db.debian.org/machines.cgi?host=amdahl.
Unfortunately, even massively increasing that timeout (to 90000000) does not help, so the issue is something else. Any pointers on how I can further debug the problem?
It looks like issue with gif format writing, reading png seems to be working (as previous tests that uses this same file passes), so it probably problem with writing part. May be just problem with conversion to 256 colors that gif require?
Maybe you could try checking if smaller images pass this test, by replacing test/img.png
with something smaller? And if that doesn't work we could just disable that gif test on that platform, i could try adding code that could do that.
I will give it a try.
Good news! I looked again with more detail, and found where to increase the timeout.
This is a long explanation, if in a hurry, go to the Increase timeout
section:
We run rebar3 (or rebar), which runs EUnit, which runs eimp erlang code, which runs eimp C code. Let's see who measures times and what are their timeout values:
CALL_TIMEOUT
in eimp_worker.erl
EUnit documentation says:
The default timeout for an individual test is 5 seconds.
With that in mind, let's add a delay in all tests:
--- a/src/eimp_worker.erl
+++ b/src/eimp_worker.erl
@@ -49,6 +49,7 @@ call(Data) ->
-spec call(binary(), non_neg_integer()) ->
{ok, binary()} | {error, eimp:error_reason()}.
call(Data, Timeout) ->
+ timer:sleep(5000),
case eimp:is_gd_compiled() of
true ->
StartTime = p1_time_compat:monotonic_time(milli_seconds),
The error message that is thrown looks close to what you get:
We see a *timed out*
error message when sleeping 5 seconds. If sleep is only 4 seconds or less, then the test suceed. This confirms the timeout is detected by EUnit, evn if it is caused by a delay in eimp.
How to change that timeout?
rebar3 documentation mentions (another mention) eunit_opts
in rebar.config
rebar2 documentation also mentions that eunit_opts
option
And EUnit documentation mentions scale_timeouts
Let's add the line:
--- a/rebar.config
+++ b/rebar.config
@@ -42,6 +42,8 @@
{xref_checks, [undefined_function_calls, undefined_functions, deprecated_function_calls, deprecated_functions]}.
+{eunit_opts, [{scale_timeouts, 10}]}.
+
%% Local Variables:
%% mode: erlang
%% End:
Great!!
Let's see again at your test results:
module 'eimp_test'
eimp_test: start_test...[0.039 s] ok
eimp_test: is_supported_test...ok
eimp_test: supported_formats_test...ok
eimp_test: png_to_jpeg_test...[0.134 s] ok
eimp_test: png_to_webp_test...[0.745 s] ok
eimp_test: png_to_gif_test...*timed out*
This only shows that five tests passed and one failed. But what about the other ones?
Those tests are defined in src/eimp_test.erl
, and are executed in the same order that the functions are defined. You can simply move the _test
functions up and down, or remove them.
My question is:
png to gif
conversion?Checks to clarify that:
Comment the function png_to_gif_test
...
If other gif conversion test fails too, then comment them it...
Move up the function png_to_gif_test
, putting it before the other conversion functions...
eimp repeatedly failed to FTBFS on armel: https://buildd.debian.org/status/package.php?p=erlang-p1-eimp&suite=sid
The eunit test
png_to_gif_test
times out. As armel is a rather low power system, I would like to know what the timeout limit is and if (and how) it can be increased.Please note that this currently blocks providing the latest ejabberd release for Debian users.