<div dir="ltr"><div>The release notes for ERTS-10.7.1 mention:</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Fixed a bug in a receive optimization. This could cause a
<span>receive</span> not to match even though a matching
message was present in the message queue. This bug was
introduced in ERTS version 10.6 (OTP 22.2).<br>Own Id: OTP-16572 Aux Id: ERL-1199, OTP-16269
</blockquote></div><div><br></div><div>We were on ERTS-10.6.2 (OTP-22.1.??). Today we reproduced it again and I knew just what to look for so:</div><div><pre style="box-sizing:inherit;margin:4px 0px;padding:8px;font-size:12px;line-height:1.50001;font-variant-ligatures:none;white-space:pre-wrap;word-break:normal;font-family:Monaco,Menlo,Consolas,"Courier New",monospace;border-radius:4px;color:rgb(29,28,29);font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:left;text-indent:0px;text-transform:none;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial">(rabbit@rabbitmq-1-0)16> lists:filter(fun({_Pid, _Ref, {sync_notify, _}}) -> false; (_) -> true end,<br>(rabbit@rabbitmq-1-0)16> element(2,recon:info(rabbit_log_connection_lager_event, messages))).<br style="box-sizing:inherit">[{#Ref<0.229770800.3298820110.79067>,ok}]</pre></div><div>And where we have it. Out of 85,000 messages or so in that worker, only one of them wasn't a blocked <span style="font-family:monospace">sync_notify</span>, and it was a message of the form <span style="font-family:monospace">{Ref, ok}</span> which entirely matches the compiler bug. I can't say for sure it's the right response, but assuming things are synchronous there's no reason we'd have another one either. We're upgrading to Erlang/OTP-22.3.1 or newer (which contains ERTS-10.7.1). I'm very surprised that the compiler bug had an effect on <span style="font-family:monospace">gen:call()</span> rather than just the branching pattern in <span style="font-family:monospace">socket<span style="font-family:arial,sans-serif"> (but somewhat relieved because it would otherwise imply another bug)</span></span>. Out of caution, we'll have engineers try to reproduce it once more to see if that fixes it.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 23, 2020 at 3:53 PM Michael Truog <<a href="mailto:mjtruog@gmail.com" target="_blank">mjtruog@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<div>On 7/23/20 9:18 AM, Fred Hebert wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>The two things I have as a theory for now is either:</div>
<div>
<ol>
<li>the reply was received but not processed (the bug at <a href="https://bugs.erlang.org/browse/ERL-1076" target="_blank">https://bugs.erlang.org/browse/ERL-1076</a>
could be at play but the bug report's optimization
requires a conditional that doesn't match the format of <span style="font-family:monospace">gen:call()</span> here)</li>
<li>the reply was "sent" but never actually enqueued in the
destination process</li>
</ol>
<br>
</div>
</div>
</blockquote>
Hi Fred,<br>
<br>
ERL-1076 was fixed in 21.3.8.11 [1] and 22.1.6 [2] (with 23.x
getting released afterwards). Are you using an older Erlang/OTP
version?<br>
<br>
Best Regards,<br>
Michael<br>
<br>
[1]
<a href="https://erlang.org/pipermail/erlang-questions/2019-November/098785.html" target="_blank">https://erlang.org/pipermail/erlang-questions/2019-November/098785.html</a><br>
[2]
<a href="https://erlang.org/pipermail/erlang-questions/2019-November/098716.html" target="_blank">https://erlang.org/pipermail/erlang-questions/2019-November/098716.html</a><br>
<br>
</div>
</blockquote></div>