[erlang-bugs] A funny bug

Anthony Ramine n.oxyde@REDACTED
Fri Aug 2 15:20:47 CEST 2013


Replied inline.

-- 
Anthony Ramine

Le 2 août 2013 à 14:03, Tony Rogvall a écrit :

> 
> 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 ;-)

There is a reason why undocumented stuff is undocumented, smiley or not.

>> 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?

There is no such a way, apart from making an extra check in the VM and thus slowing down any receive code.

> 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/257a274d/attachment.htm>


More information about the erlang-bugs mailing list