The Erlang global Livelock: A 34-Million-Iteration Bug

2026-08-30T00:00:00+00:00
We ran into an issue where a 45-node Couchbase Server cluster ran out of memory on multiple nodes at a customer site. The nodes were running OTP 25.3. The nodes that ran out of memory were OOM-killed, and the disk filled while writing 60-100 GiB crash dumps, so when they restarted, the process state was lost. The root cause was a 34-million iteration livelock in global</code>. This is how I traced it without a reproduction, using the other nodes’ logs.</p>
Day 1</h2>
The first step was figuring out which process(es) were consuming memory. The memory consumption was in ns_server</code>, but nothing noteworthy was happening at the time that memory consumption spiked. Prometheus statistics revealed nothing. I came across memsup</code> data in a text log. memsup</code> records memory usage for top Erlang consumers every minute. I parsed and plotted memsup</code> data from the one node Support had mentioned, and sure enough, there was a single offender, a process <0.56.0></code>. The memory consumed by the <0.56.0></code> process increased linearly.</p>
Day 2</h2>
I plotted the worst memory offender from memsup</code> data on all nodes in the cluster. <0.56.0></code> was the culprit on all affected nodes.</p>
It wasn’t immediately obvious what this process <0.56.0></code> referred to, so I spun up a node running the identical Couchbase Server version. <0.56.0></code> was a process registered by global</code>.</p>
global</code> is a module that is responsible for registering names on the network of nodes running the Erlang distribution protocol. It’s part of the Erlang kernel and runs whether you use it or not. From the Erlang documentation:</p>

The global name server also performs the critical task of continuously monitoring changes in node configuration. If a node that runs a globally registered process goes down, the name is globally unregistered. To this end, the global name server subscribes to nodeup</code> and nodedown</code> messages sent from module net_kernel</code>.</p>
</blockquote>
This is an Erlang kernel process that we hadn’t tweaked. We don’t use it for process registration either.</p>
I filtered the logs for global</code> function hits. One stack on node-0082 caught my attention: it contained a few messages – cancel</code>, remove_from_known</code>, his_the_locker</code> – in its mailbox. I suspected that the message queues for the process <0.56.0></code> spawned by global</code> grew indefinitely on the nodes that ran out of memory – perhaps, there was a livelock.</p>
The trigger was unclear. Since global</code> responds to nodeup</code> and nodedown</code> messages, I suspected there were network issues causing repeated node flaps. I had noticed that the nodes occasionally restarted hundreds of times. Perhaps, the connection churn exposed a race condition in global</code>.</p>
Support told me there were no network issues but that a Kubernetes upgrade had been initiated on some nodes. However, the OOM wasn’t limited to nodes that were upgraded. Nor was it the case that every node that was upgraded ran into this issue. It was unclear whether the upgrade had anything to do with it.</p>
Day 3</h2>
We record diagnostic info in cbcollect</code> dumps, which captures Erlang process info for all running processes, including their mailbox contents. I had stopped looking at process dumps after the first handful – their process state was clean as the nodes had restarted. A colleague flagged a node that still had its process dump intact. Its memory usage had increased but hadn’t run out, unlike the other nodes. They’d opened the dump and said it appeared to confirm my hypothesis – the mailbox contained 69M messages:</p>
{message_queue_len,69628685},</span></span></code></pre>
The message queue contained alternating cancel</code> and his_the_locker</code> messages with monotonically increasing tags, stepping by 1 each pair:</p>
{messages,</span></span>
[<<"{cancel,'ns_1@node-85',-576460752302537370,no_fun}">>,</span></span>
<<"{his_the_locker,<18602.56.0>,{8,[]},-576460752303387318,-576460752302537369}">>,</span></span>
<<"{cancel,'ns_1@node-85',-576460752302537369,no_fun}">>,</span></span>
<<"{his_the_locker,<18602.56.0>,{8,[]},-576460752303387317,-576460752302537368}">>,</span></span>
<<"{cancel,'ns_1@node-85',-576460752302537368,no_fun}">>,</span></span>
<<"{his_the_locker,<18602.56.0>,{8,[]},-576460752303387316,-576460752302537367}">>,</span></span>
<<"{cancel,'ns_1@node-85',-576460752302537367,no_fun}">>,</span></span>
<<"{his_the_locker,<18602.56.0>,{8,[]},-576460752303387315,-576460752302537366}">>,</span></span>
<<"{cancel,'ns_1@node-85',-576460752302537366,no_fun}">>,</span></span>
<<"{his_the_locker,<18602.56.0>,{8,[]},-576460752303387314,-576460752302537365}">>]}</span></span></code></pre>
This sequence of messages suggested that two nodes were caught in a loop where they repeatedly attempted to establish new sessions – each new session minting a new tag, one larger than the one previously used.</p>
From <0.55.0></code>’s process dictionary on node 74:</p>
{{sync_tag_my, 'ns_1@node-85'}, -576460752267720345},</span></span>
{{sync_tag_his, 'ns_1@node-85'}, -576460752268570427},</span></span></code></pre>
The difference between the current tag in the dictionary and the tags in the message queue gave the iteration count: 576460752303387318 - 576460752268570427 = ~34M</code> tags, with two messages per iteration (his_the_locker</code> + cancel</code>) producing the 69M message total.</p>
34M synchronization sessions had begun between this pair of nodes. I started looking at the global</code> source code to understand the synchronization protocol.</p>
I noticed the assumptions mentioned in global.erl</code> lines 793-799:</p>
%% In case a connection goes down and then up again, the</span></span>
%% 'nodedown' for the old connection is nowadays guaranteed to</span></span>
%% be delivered before the 'nodeup' for the new connection.</span></span>
%%</span></span>
%% By keeping track of connection_id for all connections we</span></span>
%% can differentiate between different instances of connections</span></span>
%% to the same node.</span></span></code></pre>
I wondered if the ordering of nodeup</code> and nodedown</code> was violated somehow.</p>
I filed an initial bug report containing the mailbox trace with Erlang/OTP.</p>
Separately, QA tried to reproduce the issue with Kubernetes upgrades and repeated node restarts in a large cluster, but their attempts were unsuccessful.</p>
Day 7</h2>
Reading further into the source, I found a comment about vsn 8:</p>
%% Vsn 8 - "verify connection" part of the protocol preventing</span></span>
%%         deadlocks in connection setup due to locker processes</span></span>
%%         being out of sync</span></span></code></pre>
global</code> vsn 8 of the protocol introduced reconnect attempts when the locker processes on the nodes were out of sync. I didn’t see any rate control limits in the connection attempts. I suspected that the locker processes were out of sync and flooded each other with repeated handshake attempts.</p>
How could this be related to upgrades?</h3>
When a Kubernetes node was upgraded, the Couchbase pods running on it were evicted and flagged for auto-failover since they became unreachable. Couchbase Autonomous Operator repeatedly recreated these failed pods but detected their state as unhealthy (since they had been failed over without its knowledge) until the pod was successfully added back to the Couchbase cluster. Each pod restart corresponded to an Erlang node restart with the same Couchbase node name, though the pod’s network identity likely changed – triggering net_kernel</code>’s nodeup</code> and nodedown</code> messages. global</code> triggered new synchronization session attempts in response to these messages. As soon as the pod stabilized and established connections successfully, the memory on a pair of Couchbase nodes increased linearly. My theory was that the handshake after upgrade caused some upgraded nodes to get stuck in a bad state, leading to indefinite retries and eventual OOM.</p>
The vsn 8 retry logic meant that sync sessions initiated at the time of upgrade might be interrupted by repeated restarts and retried indefinitely – with no rate limit.</p>
This was confirmed by the memory plot: pairs of nodes consumed memory in lockstep and coincided with the time of upgrade.</p>

  
    
  </a>
  Memory consumption plot showing pairs of nodes climbing in lockstep, log scale, 512 MiB to 128 GiB over the course of the day.</figcaption>
</figure>
I had a separate concern: when the session was stuck, could it lead to locks not being released?</p>
Any locks held are logged in global</code>‘s ETS tables. I parsed the global</code>-related ETS dumps in the cbcollect</code> dumps and concluded that a lock held by one of the first two nodes in the message storm (at 7:30 am in the diagram above) hadn’t been released – and that this unreleased lock potentially stalled other nodes’ synchronization attempts.</p>
I posted an update on the OTP ticket with these findings.</p>
Day 8</h2>
Since I hadn’t received any updates on the ticket, I looked further at the vsn 8 protocol, specifically the sequence of init_connect</code> and cancel_connect</code> messages during retries.</p>
I noticed this in the retry path:</p>
%% This should not be possible unless global group has</span></span>
%% been configured. We got an already ongoing connection</span></span>
%% setup with Node and get yet another connection attempt</span></span>
%% from Node.</span></span></code></pre>
I was curious what would happen if it did hit this condition.</p>
When Node B sends an init_connect</code> to Node A, it includes a session tag HisTag</code>, which identifies this sync attempt. If Node A already has Node B in its pending list (an ongoing sync session that’s in progress), Node A should cancel the old session, restart cleanly, and throw – discarding the old session with HisTag</code> entirely.</p>
Without the throw, execution falls through. Node A has just called restart_connect</code>, which wiped Node B’s state and started a fresh sync session with a new tag MyTag + 1</code>. But then the fall-through code saves Node B’s canceled HisTag</code> as if it were the current session (identified by the pair HisTag, MyTag + 1</code>).</p>
From Node B’s perspective: it received a cancel_connect</code> for the HisTag</code> session, so it discards the old session, mints a new tag and sends a new init_connect</code> with HisTag + 1</code>. Node A now finds Node B in its pending list again – because the fall-through set it incorrectly – and the cycle repeats.</p>
One missing throw. 34 million iterations.</p>
When Node B is upgraded and rejoins the cluster, it sends init_connect</code> to establish a new sync session with Node A. If Node A already has Node B in its pending list from a prior attempt, this is what happens:</p>
sequenceDiagram</span></span>
    participant B as Node B</span></span>
    participant A as Node A (global_name_server)</span></span>
    participant L as Node A (locker)</span></span>
</span>
    B->>A: init_connect(HisTag)</span></span>
    Note over A: {pending, B} already set</span></span>
    A->>B: cancel_connect(HisTag)</span></span>
    Note over A: restart_connect(MyTag)</span></span>
    Note over A: {pending, B} cleared</span></span>
    A->>L: {cancel, B, MyTag, no_fun}</span></span>
    Note over A: handle_nodeup → MyTag+1</span></span>
    A->>B: init_connect(MyTag+1)</span></span>
    Note over A: missing throw -- falls through</span></span>
    A->>L: {his_the_locker, B_locker, HisTag, MyTag+1}</span></span>
    A->>B: init_connect_ack(HisTag, MyTag+1)</span></span>
    Note over A: {pending, B} set again</span></span>
    Note over B: cancel_connect → restart → HisTag+1</span></span>
    B->>A: init_connect(HisTag+1)</span></span>
    Note over A: {pending, B} -- repeat ↑</span></span></code></pre>
Each loop iteration deposits this pair into A’s locker mailbox:</p>
Abstract                                    node0074 production values</span></span>
--------------------------------------------------------------------------</span></span>
{cancel, B,       MyTag,   no_fun}     ->  {cancel,'ns_1@node-85', -576460752302537370, no_fun}</span></span>
{his_the_locker,                       ->  {his_the_locker,</span></span>
  B_locker,                                 <18602.56.0>,</span></span>
  {8,[]},                                   {8,[]},</span></span>
  HisTag,                                   -576460752303387318,</span></span>
  MyTag+1}                                  -576460752302537369}</span></span></code></pre>
Next iteration: MyTag+1</code> becomes MyTag</code>, HisTag+1</code> arrives from B.</p>
I posted an update on the ticket: Should there be a throw</code> after the restart_connect</code>?</p>
Day 14</h2>
Rickard, an OTP maintainer, confirmed, “Great find!” He asked if we had global_groups</code> configured and why the connections kept going up and down.</p>
Neither of us had the full picture yet.</p>
Day 21</h2>
Since we weren’t able to reproduce the issue, there was some reluctance in pushing a speculative fix. Unfortunately, the customer ran into the issue again.</p>
The open question: How could an init_connect</code> arrive while a connection was marked pending?</p>
Was it possible that a global</code> init_connect</code> message arrived before the nodeup</code> from net_kernel</code>? This seemed highly unlikely based on the comments here:</p>
%% Monitor all 'nodeup'/'nodedown' messages of visible nodes.</span></span>
%% In case</span></span>
%%</span></span>
%% * no global group is configured, we use these as is. This</span></span>
%% way we know that 'nodeup' comes before any traffic from</span></span>
%% the node on the newly established connection and 'nodedown'</span></span>
%% comes after any traffic on this connection from the node.</span></span></code></pre>
and the net_kernel</code> delivery guarantees:</p>

Delivery guarantees of nodeup/nodedown messages:
nodeup</code> messages are delivered before delivery of any signals from the remote node through the newly established connection.
nodedown</code> messages are delivered after all the signals from the remote node over the connection have been delivered.
nodeup</code> messages are delivered after the corresponding node appears in results from erlang:nodes()</code>.
nodedown</code> messages are delivered after the corresponding node has disappeared in results from erlang:nodes()</code>.
As of OTP 23.0, a nodedown</code> message for a connection being taken down will be delivered before a nodeup</code> message due to a new connection to the same node. Prior to OTP 23.0, this was not guaranteed to be the case.</p>
</blockquote>
The nodeup</code>/nodedown</code> sequence in the logs was consistent – I didn’t have visibility into init_connect</code>, but nothing in the net_kernel</code> events suggested ordering anomalies.</p>
I pivoted to looking at how network connections were created and destroyed during a Kubernetes upgrade. The presence of wait_pending</code> in the net_kernel</code> logs seemed odd. I looked it up. wait_pending</code> revealed that the old connection was still alive when the new one completed its handshake – net_kernel</code> only kills the old controller at that point. This meant messages from the old session could be delivered on the new connection, unlike a clean FIN/RST disconnect where the old connection is gone before the new one is established. This might have exposed a corner condition in global</code>. During handle_nodedown</code>, a send_cancel_connect_message</code> uses erlang:send({global_name_server, Node}, Msg, [noconnect])</code> – it silently drops if there’s no connection. With wait_pending</code>, the new connection is already established when nodedown</code> fires – that’s what triggers the teardown – so the cancel goes through instead of being silently dropped.</p>
Building on this, I wondered if tags were recycled during pod restarts, and whether they could collide and confuse global</code>. I spun up Erlang VMs repeatedly and noticed that erlang:unique_integer([monotonic])</code> always starts from the same number (?MIN_64BIT_SMALL_INT</code>). This implied that repeated restarts of Node B after an upgrade could reuse tags used in previous incarnations. Might this expose a corner case in conjunction with wait_pending</code>?</p>
I established a packet sequence that could lead to the condition where Node A determined that it already had a connection when the init_connect</code> was processed.</p>

A had an in-flight sync session with B’s previous life using tag T</li>
B restarts and begins a new connection attempt, minting the same tag T from scratch</li>
Because connection termination is delayed until the new connection is accepted, a TCP connection already exists when the nodedown</code> is delivered to A. In response, A sends cancel_connect(T)</code> – and because B is reachable, it goes through. In the common case, the old connection is already gone before the new one is established, so the cancel is silently dropped and B’s new life never sees it.</li>
B recognizes cancel_connect(T)</code> as valid – the tag matches its own sync_tag_my</code> – and restarts with T+1</code>. (If it hadn’t matched, it would be silently discarded.)</li>
</ol>
Consequently, A gets two init_connect</code> messages from B, the second when it already has B in pending state.</p>
sequenceDiagram</span></span>
    participant A as A</span></span>
    participant B as B (new life, tag=T)</span></span>
</span>
    Note over A: mailbox: [nodedown(B), nodeup(B)]</span></span>
    Note over B: New connection fully established</span></span>
    Note over B: nodeup(A) fires</span></span>
    B->>A: init_connect(T)</span></span>
    Note over A: processing nodedown(B) -- old session tag = T (B's previous life)</span></span>
    A->>B: cancel_connect(T) -- B is reachable, send goes through</span></span>
    Note over B: sync_tag_my = T -- T == T? Yes, restart fires</span></span>
    B->>A: init_connect(T+1)</span></span>
    Note over A: processing nodeup(B)</span></span>
    Note over A: processing init_connect(T) -> {pending, B}</span></span>
    Note over A: processing init_connect(T+1) -- {pending,B} set -> livelock</span></span></code></pre>
I was not able to reproduce this specific condition, but pushed the speculative fix (the missing throw) to the customer. The issue hasn’t recurred. Rickard fixed it upstream in OTP shortly after.</p>
Conclusion</h2>
The missing throw is the confirmed bug: once two nodes ended up in the state where {pending, B}</code> was already set when a new init_connect</code> arrived, the livelock was inevitable – unbounded retries, no error logged, memory growing silently. Each iteration deposited exactly the alternating cancel</code> and his_the_locker</code> pairs found in the production mailbox – 34M iterations, two messages each, 69M total.</p>
What’s less certain is how that precondition arose. The most plausible path involves two things coinciding: wait_pending</code> delaying teardown of the old connection long enough for messages from the old global</code> synchronization session to be delivered on the new one, combined with tag reuse – every Erlang VM starts minting tags from ?MIN_64BIT_SMALL_INT</code> on boot, so a restarted pod can issue a tag that collides with one the peer still has in flight from the pod’s previous incarnation. I wasn’t able to reproduce this specific sequence, but the fix held.</p>
his_the_locker</code>, HisTag</code>, and related names appear verbatim from the Erlang source.</p>
References</h3>

OTP issue: erlang/otp#9117</a> – filed Nov 26, 2024, assigned to Rickard Green (OTP maintainer)</li>
Affected version: OTP 25.3</li>
Fixed in: OTP 25.3.2.17</li>
Relevant source: lib/kernel/src/global.erl</code></li>
</ul>
`References</h3> OTP issue: erlang/otp#9117</a> – filed Nov 26, 2024, assigned to Rickard Green (OTP maintainer)</li> Affected version: OTP 25.3</li> Fixed in: OTP 25.3.2.17</li> Relevant source: lib/kernel/src/global.erl</code></li> </ul>`

Neelima

The Erlang global Livelock: A 34-Million-Iteration Bug
