The Mystery of the Vanishing Message's Dead Lock

[Andreas Schultz]

Fred,

The original report for the socket related message problem actually spawned
two fixes. The reproducer for that bug did not use gen_server, but my
original problem did occur within one.
One fix was the compiler issue in ERL-1076 that you mentioned in your first
email. The other was OTP-16241 [1] and [2]. This second problem feels a bit
like your issue.

Regards,
Andreas

[1]: http://erlang.org/pipermail/erlang-questions/2019-October/098660.html
[2]:
https://github.com/erlang/otp/commit/b1e7e16032b719cb62280b7f6095fce51aa8b7b2


Am Fr., 24. Juli 2020 um 00:59 Uhr schrieb Michael Truog <mjtruog@REDACTED
>:

> On 7/23/20 1:52 PM, Fred Hebert wrote:
>
> The release notes for ERTS-10.7.1 mention:
>
> Fixed a bug in a receive optimization. This could cause a receive 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).
>> Own Id: OTP-16572 Aux Id: ERL-1199, OTP-16269
>
>
> We were on ERTS-10.6.2 (OTP-22.1.??). Today we reproduced it again and I
> knew just what to look for so:
>
> (rabbit@REDACTED)16> lists:filter(fun({_Pid, _Ref, {sync_notify, _}}) -> false; (_) -> true end,
> (rabbit@REDACTED)16>              element(2,recon:info(rabbit_log_connection_lager_event, messages))).
> [{#Ref<0.229770800.3298820110.79067>,ok}]
>
> And where we have it. Out of 85,000 messages or so in that worker, only
> one of them wasn't a blocked sync_notify, and it was a message of the
> form {Ref, ok} 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 gen:call() rather than just the
> branching pattern in socket (but somewhat relieved because it would
> otherwise imply another bug). Out of caution, we'll have engineers try to
> reproduce it once more to see if that fixes it.
>
> The erts-10.6.2 release was included in Erlang/OTP 22.2.2 [1], so it must
> be that release or a custom release based on it.  The erts-10.7.1 release
> with Erlang/OTP 22.3.1 [2] does have an important fix (OTP-16572 is the
> Ericsson identifier and ERL-1199 is the bugs.erlang.org identifier) since
> that should impact all the OTP behaviors that create synchronous messages
> (due to taking advantage of the {Ref, _} optimization).  Good to know, to
> make sure development is using a version >= 22.3.1.
>
> [1] https://erlang.org/pipermail/erlang-questions/2020-January/098996.html
> [2] http://erlang.org/pipermail/erlang-questions/2020-April/099386.html
>


-- 

Andreas Schultz

-- 

Principal Engineer

t: +49 391 819099-224

------------------------------- enabling your networks
-----------------------------

Travelping GmbH
Roentgenstraße 13
39108 Magdeburg
Germany

t: +49 391 819099-0
f: +49 391 819099-299

e: info@REDACTED
w: https://www.travelping.com/
Company registration: Amtsgericht Stendal
Managing Director: Holger Winkelmann
Reg. No.: HRB 10578
VAT ID: DE236673780
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20200724/6e13c904/attachment.htm>