Build failed on mips and sh4 at Debian about meck HOT 12 CLOSED

If you have access to the machines (or architectures) in question, you could try to debug the error. The test case can be found here: https://github.com/eproxus/meck/blob/develop/test/meck_tests.erl#L922

My suggestion would be to run the test case in isolation first, to see if it still is a problem:

rebar eunit tests=cover_test

The next step would be to enable tracing on the functions called in the test, to see where it hangs. You can add this to the top of the test case:

cover_test() ->
    dbg:tracer(), dbg:p(all, call),
    [dbg:tpl(cover, F, x)|| F <- [compile, analyze]],
    [dbg:tpl(meck_test_module, F, x) || F <- [a, b, c]],
    [dbg:tpl(meck, F, x) || F <- [new, expect, unload]],
    dbg:tpl(filelib, is_file, x),
    ...

Then just run the test case again, preferably using the tests=... argument to Rebar to avoid tracing from the rest of the tests.

from meck.

Closing until further updates.

from meck.

Actually I have some news here. It seems that the issue is still there, and I can reproduce it quite easily on one machine I have access to (PPC64 achitecture). Interesting thing is that the issue is rather floating - take a look at the failure arch matrix from two different build attempts:

• https://koji.fedoraproject.org/koji/taskinfo?taskID=20612043
• https://koji.fedoraproject.org/koji/taskinfo?taskID=20750860

I'll post update in a few days.

from meck.

@lemenkov Is it the same error? I can't seem to find the build log for those new builds...

from meck.

@eproxus I believe it's almost the same (unfortunately failed build logs are getting disposed rather fast in Fedora Project). "Almost", because I see some difference - I've got an io premature shutdown failure (very similar to this one - https://stackoverflow.com/questions/6491897/erlang-spawn-problems/6499774#6499774 ) instead of getting timeout.

from meck.

I'll post new logs shortly.

from meck.

Would like new logs since the last ones are four year old 😄 A lot happened in Meck after that (including changing build system to Rebar 3)

from meck.

Sorry for being late. Expect a fix soon.

from meck.

Yes, this cannot be reproduced with Rebar3, so this issue is related to Rebar2. I cannot find a specific reason for behaving like that, but finally found a fix. Apparently Rebar2 ion these arches doesn't like when you do meck:new(...) followed by meck:unload(). It must be moved into a fixture (foreach).

This is a Rebar2-specific issue, and I cannot reproduce it with a Rebar3. Also I tested patched version with Rebar3 on my PPC64 - it works. And since it doesn't hurt any Rebar3 user so why not to apply it? :)

from meck.

What is the actual error? Just timeouts?

from meck.

@eproxus that's the tricky question. And I still can't answer.

I wasn't able to pinpoint an exact issue, but it seems that on some architectures (can't say Big-Endian), rebar can run tests in the way they can interfere with each other. I believe this indeed has something with timeouts. All the trests are running fine if running test-suites separately.

What I've changed is a very little thing. I've reorganized test-cases in two test-suites so they now have setup/teardown functions where all meck:new(...) / meck:unload() happens. So no meck:new(...) / meck:unload() can happen in the middle of other tests (?) or in any other unwanted time. This fixes the issue.

To sum up:

• something shut down io server during meck_tests:cover_test() on some architectures when using rebar2.
• reorganization of a two test-suites from a bunch of isolated test-cases framed with meck:new(..) / meck:unload() calls into a test-suite with setup/teardown apparently helped rebar2 to run all of the tests properly.

from meck.

Yeah, this whole thing seems very messy. Fortunately, the refactoring doesn't really change anything and in fact the suites contain less repetition 😄

Thanks for doing the research, I'll merge it. Let me know how it works!

from meck.