[erlang-questions] Erlang 18.0, hanging erlang:memory(total)?

Sverker Eriksson sverker.eriksson@REDACTED
Fri Jul 3 15:32:52 CEST 2015


On 07/02/2015 10:42 PM, Nico Kruber wrote:
> On Thursday 02 Jul 2015 14:23:01 Rickard Green wrote:
>> On Thu, Jul 2, 2015 at 12:29 AM, Nico Kruber<nico.kruber@REDACTED>  wrote:
>>> Hi folks,
>>> is it possible that erlang:memory/1 can hang?
>>>
>>> Today I had a unit test failing in the middle of its execution (it runs
>>> the
>>> same test over and over again and it was like the 20th time it was run).
>>> There was a timeout (>50s) in one process not being able to finish its
>>> message handling and erlang:process_info(Pid, current_stacktrace) is
>>> repeatedly showing the following stacktrace during these 50s:
>>>
>>> {current_stacktrace,
>>>
>>>               [{erlang,receive_emd,3,[]},
>>>               
>>>                {erlang,get_mem_data,3,[]},
>>>                {erlang,memory,1,[]},
>>>                {dht_node_state,details,1,
>>>                
>>>                    [{file,"src/dht_node_state.erl"},{line,510}]},
>>>                
>>>                {dht_node,on,2,[{file,"src/dht_node.erl"},{line,384}]},
>>>                {mockup_dht_node,on,2,
>>>                
>>>                    [{file,"test/mockup_dht_node.erl"},{line,67}]},
>>>                
>>>                {gen_component,on,3,
>>>                
>>>                    [{file,"src/gen_component.erl"},{line,614}]}]}
>>>
>>> The line in the dht_node_state module literally only calls
>>> erlang:memory(total) and creates a record with this info. Apparently, it
>>> never gets out of erlang:memory/1 :(
>>>
>>>
>>> Thanks for your help
>>> Nico
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
>> The bug fixed in OTP-18.0.1 (and OTP-17.5.6.1) can cause such a hang.
>>
>> Regards,
>> Rickard
> ok, I'll keep an eye on 18.0.1 on our test systems
> -> note however, that I encountered the bug not "just after emulator start" as
> stated in the release log. Also since I ran several tests before the failing
> one, several calls to erlang:memory/1 succeeded before the hang!
>
>
> Nico
>
The bug fixed in 18.0.1 (OTP-12859) is not specific to emulator start,
but that is only where we have seen it so far, and we think the VM might be
extra vulnerable for this bug at start.
The bug is in the general logic to wake up scheduler threads
that is blocking for IO events, and can happen "anytime". It's a very 
specific
race between threads however, so you have to be quite unlucky for it to 
happen.

The symptom is actually never an eternal hanging as the polling thread will
eventually be released by its next finite timeout, which can be anything 
from
a couple of milliseconds to several hours.

/Sverker, Erlang/OTP

...



More information about the erlang-questions mailing list