[erlang-questions] enif_send() and overrun heap

[Guilherme Andrade]

I've distilled the flow that triggers the crash and made a demo.

    https://github.com/g-andrade/enif_send_crash

It implements a dirty NIF which sends messages to a second process using
enif_send() and a message containing a heap-allocated term.
It increases the number of iterations exponentially until it crashes.

This is what happens in my machine very consistently (macOS):

> ./enif_send_crash
> Trying to crash (1 iterations)...
> Trying to crash (2 iterations)...
> Trying to crash (4 iterations)...
> Trying to crash (8 iterations)...
> Trying to crash (16 iterations)...
> Trying to crash (32 iterations)...
> Trying to crash (64 iterations)...
> Trying to crash (128 iterations)...
> Trying to crash (256 iterations)...
> Trying to crash (512 iterations)...
> Trying to crash (1024 iterations)...
> beam/erl_nif.c:445:cache_env() Assertion failed: env->hp_end ==
(env->proc)->stop


On 7 August 2018 at 09:38, Guilherme Andrade <g@REDACTED> wrote:

> Hi,
>
> On 20 June 2018 at 18:39, Sverker Eriksson <sverker.eriksson@REDACTED>
> wrote:
>
>> I suggest you (and everybody during NIF development) to run on a debug-VM.
>> It's slower but it catches a lot of faults earlier and produces a nicer
>> core
>> dump. It will catch enif_* API violations such as building
>> tuples/lists/maps
>> with terms from different environments.
>>
>
> I finally found the time to look into this matter again.
>
> Using a debug build of the VM (20.3), the crash consistently happens due
> to a failed assertion in line 445 of erl_nif.c[1].
> Other conditions are the same as before.
>
> Is this enlightening in anyway? I've got a 2.8 GiB core dump I can look
> into if you tell me that's the right direction to go.
>
>
> [1]: https://github.com/erlang/otp/blob/OTP-20.3.8.4/erts/
> emulator/beam/erl_nif.c#L445
>
> --
> Guilherme
>



-- 
Guilherme
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20180807/d96ec156/attachment.htm>