[erlang-questions] How to diagnose stuck Erlang node

dennis.novikov@REDACTED dennis.novikov@REDACTED
Mon Nov 28 12:51:36 CET 2011


+48 does not point to an instruction start on a couple of 32-bit systems I  
have access to, so I can not assist you further.

To get instructions dump named "user_drv.dis" in the beam process working  
directory you can do

erts_debug:df(user_drv).

Happy bug-hunting.


On Mon, 28 Nov 2011 12:01:17 +0200, Kirill Zaborsky <qrilka@REDACTED>  
wrote:

> I'm using halfword emulator on 64bit Ubuntu Server
> And the process state is not "waiting" but "running". Previous crash  
> dumps
> show the same program counter value (and user_drv in running state)
>
> Kind regards,
> Kirill Zaborsky
>
>
> 2011/11/28 Dennis Novikov <dennis.novikov@REDACTED>
>
>> On Mon, 28 Nov 2011 08:44:42 +0200, Kirill Zaborsky <qrilka@REDACTED>
>> wrote:
>>
>>  Trying to fins any workaround to this "stuck node" scenario I've  
>> upgraded
>>> to R14B04 and turned on "heart".
>>> But recently  the node once again stopped responding. And heart did not
>>> assume it to be stuck although I could not contact it.
>>> I've tried to to get a crashdump with 'kill -USR1' but it appeared that
>>> once again crash dump was truncated. Does heart kills "dead" erlang  
>>> node?
>>> And the only thing that could be seen from the crash dump that the only
>>> running process was user_drv (just like in previous times) with program
>>> counter equal to "user_drv:server_loop/5 + 48". Is it possible to find  
>>> out
>>> what exactly does it stands for?
>>>
>>
>> Waiting on receive in that function. And you are observing this on a
>> 32-bit VM.
>>
>> --
>> WBR,
>>  DN
>>


-- 
WBR,
   DN



More information about the erlang-questions mailing list