<div dir="ltr">Hmm, I think there's more to it. The source shows that dirty schedulers *are* specifically handled in enif_send(), so something else is up.<div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, 20 Jun 2018 at 09:18 Guilherme Andrade <<a href="mailto:g@gandrade.net">g@gandrade.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div data-smartmail="gmail_signature" dir="auto"><br></div><div class="gmail_quote" dir="auto"><div dir="ltr">On Wed, 20 Jun 2018, 14:42 Daniel Goertzen, <<a href="mailto:daniel.goertzen@gmail.com" rel="noreferrer" target="_blank">daniel.goertzen@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I wonder if running under a dirty scheduler counts as "running from a created thread" in which case the first parameter to enif_send() should be NULL.</div></blockquote></div><div dir="auto"><br></div></div><div dir="auto"><div dir="auto">Good point! That seemed to do it, thanks.</div><div dir="auto"><br></div><div dir="auto">May someone from OTP team confirm dirty schedulers count as created threads for enif_send? (It makes perfect sense they would, but it's best to check.)</div><div dir="auto"><br></div><div dir="auto">If confirmed, maybe I'll do a PR to make documentation more explicit about this corner case.</div></div><div dir="auto"><div dir="auto"><br></div><div dir="auto"><br></div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><div class="gmail_quote"><div dir="ltr">On Wed, 20 Jun 2018 at 08:30 Guilherme Andrade <<a href="mailto:g@gandrade.net" rel="noreferrer noreferrer" target="_blank">g@gandrade.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hello list,</div><div><br></div><div>I'm bumping into a weird issue in OTP 20.3 (macOS) whereby calling enif_send() a few dozen times a second from a dirty scheduler (CPU bound), with msg_env=NULL, results in heap overrun.</div><div><br></div><div>These is the flow that sooner or later results in heap overrun:</div><div><br></div><div>1) Single Erlang process makes a specific NIF call ~25 times per second (dirty scheduler, CPU bound)<br></div><div>2) This call will receive a few network packets (non-blocking)<br></div><div>3) Each of these packets gets wrapped in a tuple (allocated in process env)<br></div><div>4) For each of these wrapped packets, a lookup is made in a map, passed as a NIF argument, for a process dedicated to handling this particular packet<br></div><div>5.a) If the lookup succeeds, enif_send() is called to dispatch the wrapped packet to said dedicated process (with msg_env=NULL) - this is what happens to most packets<br></div><div>5.b) If the lookup fails, the wrapped packet is accumulated and later returned to the NIF caller</div><div><br></div><div>Now, when total packets per second increase to a few dozen, sooner or later (sometimes as soon as after ~10 seconds) the VM stops abruptly with this error message:<br><br>> hend=0x0000000013655fa0<br>> stop=0x0000000013655ef8<br>> htop=0x00000000136562c8<br>> heap=0x0000000013652db0<br>> beam/erl_gc.c, line 708: <0.506.0>: Overrun stack and heap</div><div><br></div><div>(The pid mentioned above corresponds to the NIF caller.)</div><div><br></div><div>I tried three things (independently) that prevent the overrun from happening under this load:<br></div><div>A) Increasing the NIF caller heap size from the default (233 words) to 23300 words<br></div><div>B) Not running the NIF under a dirty scheduler<br></div><div>C) Not calling enif_send<br><br></div><div>Any ideas on why the overrun happens? Am I missing some very obvious transgression in the way enif_send() or dirty schedulers are supposed to be used?<br></div><div><br></div><div><br>-- <br><div class="m_-4800450323373009350m_160536951815044631m_-8400994105760618384m_5588283330540823104gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Guilherme<br></div></div></div></div></div></div>
</div></div>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" rel="noreferrer noreferrer" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer noreferrer noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div>
</blockquote></div></div></blockquote></div>