Skip to content

Passthrough crashes without +debug_info #14

Open
eproxus opened this Issue May 6, 2010 · 6 comments

3 participants

@eproxus
Owner
eproxus commented May 6, 2010

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.

@eproxus eproxus was assigned Jul 25, 2011
@horkhe
horkhe commented Oct 23, 2012

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

@eproxus
Owner
eproxus commented Oct 24, 2012

Yes, with a more informative error.

This was referenced Aug 12, 2013
@eproxus eproxus removed this from the 1.0 milestone Jun 17, 2015
@headcrabmeat

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
Owner
eproxus commented Mar 2, 2016

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:

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.

@headcrabmeat

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
Owner
eproxus commented Mar 4, 2016

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

@eproxus eproxus removed their assignment Mar 4, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.