Re: bug#54458: 27.2; erc-dcc-get: Re-entering top level after C stack overflow

[J.P.]

Hi Fernando,

In your initial report, you mentioned having trouble receiving multiple
files.

> If I transfer multiple files (three or four), sometimes with sizes
> smaller than those mentioned above, the C stack overflow hits way
> earlier.

Did you mean successively or simultaneously? Because when attempting the
latter, I can't even get off the ground. Specifically, when I try to get
two transfers going [1], the first freezes the moment the second starts.
And no further packets are exchanged for the first connection. So, as
far as simultaneous transfers are concerned, it may be that the changes
you so kindly tried didn't introduce a regression after all and that a
preexisting (though possibly related) bug has emerged.

>> The only different behaviors I noticed in Emacs was the fact that it
>> stops responding when transfers go beyond a certain percentage of
>> completion (I couldn't be sure of the number, but in my experiments it
>> happens above 45%) and the impossibility of transferring more than one
>> file at the same time.

That last part sounds like it may be similar to what I ran into. If so,
we may be in luck. It appears that, with a couple simple tweaks, I'm
able to successfully complete simultaneous transfers of large files.
However, retaining a responsive Emacs is another issue. Assuming the
sender misbehaves and the changes you last tried are also applied, I
lose control of Emacs the instant a send is blocked and only regain it
once all (simultaneous) transfers have completed, which seems more or
less in line with what you describe [2].

When you get a chance, please try the proposed multi-file fix, even
though it does nothing for the unresponsiveness problem. Also, if it's
not too much trouble, would you mind doing something like

  # tcpdump -i eno1 -Uw ./dump 'host 93.184.216.34 and tcp port 9899'

from before connecting until the unresponsiveness starts and then
uploading ./dump somewhere (like an s3 bucket)? Thanks.


[1] On Emacs 29, without any of the proposed changes applied:
    a. Start two emacs -Q instances, a sender and a receiver
    b. Start two helper scripts, each serving a different large file
    c. Offer both files on the sender
    d. Accept both files on the receiver

[2] To be clear, I'm still able to issue a quit signal, which results in
    a message about an error in the process filter. However, it does
    nothing to interrupt the actual process (info "(emacs) Quitting").
    And, FWIW, the first blocked send attempt never actually returns to
    the calling process filter, at least in my crude simulation.

0003-Allow-matching-against-string-values-in-erc-dcc-memb.patch
Description: Text Data

serve.py
Description: Binary data