emacs-erc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Duplicate messages from bouncers on 27 and earlier


From: J.P.
Subject: Duplicate messages from bouncers on 27 and earlier
Date: Fri, 10 Sep 2021 05:43:45 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Libera.Chat user aindilis recently reported seeing incoming messages
multiple times (once per connection) on an Emacs 26.1 connected to a ZNC
1.7.2 instance. I was able to reproduce this using Emacs 27.2 and ZNC
1.8. What's more, when applying the same repro recipe to a fresh 28 [1],
symptoms differed only superficially [2], suggesting all roads lead to
bug#48598 (and its predecessors). The attached logs paint the whole
picture, but here's a basic rundown:

On 27, with two connections and one "common" channel, only two buffers
are created: a server buffer, claimed by both processes (in a seesawing
tug of war), and a channel buffer, which goes to the most recently
JOIN'ed (here, the second process [3]). As a result, the first process
must resort to using the disputed server buffer for displaying its
orphaned messages. But since that's "shared", it's forced to wait while
messages pile up. And before long, it misses a PONG or two, and a
timeout is triggered to sever the connection [4].

After this, the reconnect facility swoops in and tries to do its job,
but it can only see connection properties belonging to the second
process. That's because all local vars get clobbered whenever `erc-open'
runs. Anyway, the punchline is that ZNC is perfectly happy to serve two
effectively identical connections, which is where all the dupes come
from.

[1] See scratch.log, attached.

[2] Mainly on account of 88567ca8ec "Fix erc-reuse-buffers behavior":

    https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=88567ca8ec

[3] In the attached logs, the first connection is called "foonet" and
    the second "barnet".

[4] Search for "Timeout" in protocol.log (attached). Note that the
    logger's labels also get confused, and it's actually foonet's
    process that dies.


Attachment: chan.log
Description: Text document

Attachment: ibuffer.log
Description: Text document

Attachment: protocol.log
Description: Text document

Attachment: scratch.log
Description: Text document

Attachment: server.log
Description: Text document

Attachment: znc.log
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]