Passthrough crashes without +debug_info

[eproxus]

When meck:new(Mod, [passthrough]) is called to mock a module that is not compiled with +debug_info it will still return ok.

When a call is made to a function in that module it crashes:

1> meck:new(mymod, [passthrough]).
ok
2> mymod:function().
** exception error: undefined function mymod_original:function/0
     in function  meck:exec/4
     in call from mymod:function/0
        called as mymod:function()

The fault is that the renamed original was never created.

[horkhe]

Reproduced. The resolution would be to make new fail, right?

[eproxus]

Yes, with a more informative error.

[stchar]

Hi,

This is still actual in version 0.8.2 however I have a little bit precise description of an issue.

I compile mymod with rebar with options erl_opts {[no_debug_info]}, and eunit_compile_opts{[debug_info]}
as a result:

• ebin/mymod.beam file has no debug info
• .euinit/mymod.beam compiled with debug info

Then I execute the test I expect meck uses mymod:funtcion/0 from .euinit/mymod.beam
however in fact meck uses it from ebin/mymod.beam

As a result when I run following commands. Meck fails:

erl
>meck:new(mymod, [passthrough]).
ok.
>mymod:function().
exception error: undefined function mymod_original:function/0
 in function  meck:exec/4
 in call from mymod:function/0
    called as mymod:function()

However if I delete ebin/mymod.beam meck works fine.

Do you have an ideas what could be wrong?
Can you suggest what places in meck sources I need to look close?

[eproxus]

First thought is that maybe both folders are on the path, with ebin being in front. Thus, it is actually that module that is loaded. You can check this with code:get_path().

Nothing is done about this yet in Meck, unfortunately. Some starting points:

• https://github.com/eproxus/meck/blob/master/src/meck_proc.erl#L349

  This is where the original code is fetched. I think in the case of no debug_info this would throw no_abstract_code which in turn would lead to no renamed original module.

• https://github.com/eproxus/meck/blob/master/src/meck_proc.erl#L430

  This is where we still created the expects for the passthrough functions, even though they don't point anywhere.

Preferably the solution is to bail out somewhere earlier, for example when detecting that there is no abstract code for the original module. In that case, the passthrough option doesn't make sense anymore.

[stchar]

Yeah, you were right about the path. It's because I'm using rebar eunit and I actually didn't understand how rebar works. In fact before rebar runs eunit it updates codepath prepending ebin dirs of deps and .eunit folder of the module is being tested.

I run it like
cd mymodule
ERL_FLAGS="-pa ../common/.eunit" rebar eunit
(I'm mecking my common module)

I expect that application path would be like

<root_dir>/common/.eunit
<root_dir>/mymodule/.eunit
<root_dir>/common/.ebin

In fact rebar makes it

<root_dir>/mymodule/.eunit  - result of rebar_eunit:setup_path()
<root_dir>/common/.ebin       - result of rebar_eunit:setup_path()
<root_dir>/common/.eunit

Shame on me...

All in all I think that this not a meck issue. Thanks for your help and sorry for disturb.

[eproxus]

Thanks for looking into it. Contributions for enhancing the error message are still welcome!

[eproxus]

Closing because of inactivity. Please re-open if it is still an issue!