[erlang-bugs] A funny bug

Tony Rogvall tony@REDACTED
Fri Aug 2 14:03:56 CEST 2013


On 1 aug 2013, at 22:29, Anthony Ramine <n.oxyde@REDACTED> wrote:

> Hello,
> 
> It's not that you should not use prim_eval in this particular manner, you should not use prim_eval at all. This is probably not the only primitive that can make the VM segfault.

Well I am, indirectly, using prim_eval:'receive'/2 when I am executing "receive Y -> Y end" from the shell.
I think that this should still be allowed. (need a smily here? I guess, ok here it is ;-)

> 
> That being said, when I implemented that patch the function didn't call a given closure but an hard-coded remote function in prim_eval; maybe we should put that back?

I like prim_eval:'receive'/2 the way it is right now. But, for example, a badarg when trying to do receive within the function closure would be nice.
I guess OTP team can figure out a lightweight way of doing this?

Regards

/Tony

> 
> Regards,
> 
> -- 
> Anthony Ramine
> 
> Le 1 août 2013 à 20:06, Tony Rogvall a écrit :
> 
>> I was inspecting the new, and long awaited for, fix of 'receive' in erl_eval.
>> 
>> I could not help myself to wonder what would happened if:
>> 
>> 5> self() ! x, prim_eval:'receive'(fun(X) -> receive Y -> Y end end, 1000). 
>> 
>> Bus error: 10
>> 
>> I know you should not use prim_eval in this manner, but I tend to ignore recommendations.
>> But this construct should probably not crash the VM.
>> 
>> /Tony
>> 
>> _______________________________________________
>> erlang-bugs mailing list
>> erlang-bugs@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-bugs
> 

"Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix"



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20130802/f7a436b4/attachment.htm>


More information about the erlang-bugs mailing list