[erlang-questions] Weird problem with "receive after ..."

Erik Søe Sørensen <>
Tue Oct 22 18:50:03 CEST 2013


Two ideas:
- The shell's receive-after implementation was flawed until recently (I
*think* it was fixed...): The timeout was reset upon the receipt of *any*
new message.
- On some virtualized environments, the high-resolution timer is flawed:
once every perhaps 100 milion reads, it jumps by a very large amount, then
jumps back. This can be deadly to the Erlang VM. (And also the JVM, by the
way). Wheter the platform has this problem can be checked by writing and
running a small C program which reads the timer ("gethrtimer"?) as often as
it can, checking for time jumps each time.

Good luck hunting...
2013/10/22 Ferenc Holzhauser <>

> Thanks for the suggestions and hints.
>
> I think I accidentally found a strange workaround.
> Spawned a simple recursive function doing this inside:
>
> receive after 500 -> io:format("~p", [calendar:local_time()]) end
>
> so I can see when exactly it stops working and perhaps find something
> around that time in the logs.
>
>
> Since doing this, I can't reproduce the issue. Now I spawn the function
> without the io:format bit (returning ok) and the VM is stable (so far).
>
> It doesn't make a lot of sense to me and I'm really curious to find out
> what is happening.
> Perhaps someone with better understanding than mine of the internals of
> "receive after" has some ideas what situation can deadlock it this way.
> Probably there are not many ways to "achieve" that.
>
> Could it be possibly related to SCTP socket handling? Namely that's the
> only thing (remote disconnect/reconnect) I could see my application was
> doing around when the problem might have happened.
>
> Regards,
> Ferenc
>
>
>
>
> On 19 October 2013 21:51, Anthony Molinaro <>wrote:
>
>> I don't know if a work around probably make sure you are running the most
>> recent version of virtual box?  And make make sure to give it multiple
>> cores.  You could also convert the vm to a different format (like VMware),
>> and see if it works better.
>>
>> -Anthony
>>
>> On Oct 18, 2013, at 1:29 PM, Ferenc Holzhauser <
>> > wrote:
>>
>> Hi Anthony,
>>
>> That must be it: it is running in virtualbox indeed. Are you aware of any
>> workaround/fix to try? I'm quite attached to this VM setup. Would be great
>> if I could make it work reliably.
>>
>> Ferenc
>> On Oct 18, 2013 9:35 PM, "Anthony Molinaro" <>
>> wrote:
>>
>>> Are you running in some sort of virtualized environment.  I seem to
>>> recall noticing some oddness with timer:send_interval/2 under VMware at one
>>> point, but it's a total guess so may not be your issue at all.
>>>
>>> -Anthony
>>>
>>> On Oct 18, 2013, at 11:50 AM, Ferenc Holzhauser <
>>> > wrote:
>>>
>>> > Hi,
>>> >
>>> > On my development system sometimes "receive after..." starts hanging
>>> after a while.
>>> > I know "sometimes" is not very helpful but I couldn't find any
>>> obviously related event yet that might trigger it.
>>> >
>>> > From that point it stops working in the whole VM e.g. I can type
>>> "receive after 10 -> ok end." in the shell and watch it never returning. Of
>>> course it also breaks most of the things that need timer.
>>> > Normal receive keeps working fine, the issue is related to timeout
>>> only.
>>> >
>>> > It is R16B01 and I'm not using any self made NIFs, drivers or other
>>> funny things that could break the VM.
>>> >
>>> > Thank you for any hints or suggestions about the possible reason/fix
>>> in advance.
>>> >
>>> > Regards,
>>> > Ferenc
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > erlang-questions mailing list
>>> > 
>>> > http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>
>
> _______________________________________________
> erlang-questions mailing list
> 
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20131022/e985dc19/attachment.html>


More information about the erlang-questions mailing list