Open ferd opened 7 years ago
Thanks for trying out CutEr and for the bug report @ferd. I can confirm what you report (using 19.0).
As mentioned in my talks, CutEr does not support maps yet (perhaps we should also mention this in the top-level README?). Still, this behavior you show is certainly weird. I suspect something breaks in the Core Erlang passes, due to the presence of the maps, and this error is not caught as a compilation/annotation error of CutEr but is reported as an execution error. Last week we saw something similar (with reporting error for the concolic execution when execution reaches bitstring primops that CutEr currently does not support) and fixing that issue is high on the TODO list. Now we have one more example. Thanks.
Granted that CutEr should report these failures in a better way, but it seems that the root of this issue is related to the fact that the Core Erlang pattern matching compilation fails for modules that contain maps
Erlang/OTP 19 [erts-8.0] [source] [64-bit] [smp:64:64] [async-threads:10] [hipe] [kernel-poll:false]
Eshell V8.0 (abort with ^G)
1> c(fail, [debug_info]).
{ok,fail}
2> c(fail, [debug_info, {core_transform, cerl_pmatch}]).
fail.erl: error in core transform 'cerl_pmatch': {{case_clause,map},
[{cerl_pmatch,expr,2,[]},
{cerl_pmatch,expr,2,[]},
{cerl_pmatch,expr,2,[]},
{cerl_pmatch,expr,2,[]},
{cerl_pmatch,'-expr/2-lc$^0/1-3-',2,
[]},
{cerl_pmatch,'-expr/2-lc$^0/1-3-',2,
[]},
{cerl_pmatch,expr,2,[]},
{cerl_pmatch,core_transform,2,[]}]}
error
We will try to fix this. In the meantime you may want to use the CutEr option --disable-pmatch
for such modules. (However, be aware that the concolic execution will be significantly slower.)
$ cuter fail id '[42]' -r
Compiling fail.erl ... OK
Testing fail:id/1 ...
fail:id(42)
=== Inputs That Lead to Runtime Errors ===
#1 fail:id(42)
$ cuter fail id '[42]' -r --disable-pmatch
Compiling fail.erl ... OK
Testing fail:id/1 ...
.
No Runtime Errors Occured
Hi,
is there any updates on this issue? I guess --disable-pmatch
is still the only way forward here?
Thanks for your awesome software & effort! :)
Hello @ioolkos,
Yes, this is still the only option. We are currently finishing up on some tasks regarding the support for recursive types in type specifications.
Since there is interest in the maps functionality, we'll discuss with @kostis to re-prioritize this issue. We'll let you know soon! :)
Great to hear! thanks :)
Try the following module definition:
Then run the following:
If the function
mapfun
is removed, everything passes.If the function mapfun is instead re-defined as:
The test for
fail:id(1)
works, but still errors out with:System information: