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

[J.P.]

Mattias Engdegård <mattiase@acm.org> writes:

> Thanks for testing. As you say, you probably want to fix this in Lisp in ERC
> in any case and doing so does not appear to be very difficult.
>
> Partly for this reason I'm not insisting on the proposed C level fix. It does
> seem to be a reasonable change though, and we usually prefer fixing a problem
> to documenting it.

Whatever happens, its insights have provided the key to fixing things on
the ERC side. So, at the very least, it'll always live on in spirit!

                               . . .

Fernando,

Please forget about the packet-capture thing. Setting that up and poring
over the results is kind of a drag. As far as trying out patches,
there's certainly no rush. While I'm sure you're probably all set,
others wanting to play along may need a hand. I'm no Arch Linux wiz, but
these steps have worked for me in the past:

1. cd ~/my-emacs-arch-repo

2. makepkg --syncdeps --nobuild

3. # if tarball
   cd ./src/emacs-<pkgver> && patch -p1 < /tmp/0002-*.patch && cd -

   # else if git
   git -C ./src/emacs-<pkgver> am /tmp/0002-*.patch

4. makepkg --force --noextract --holdver

5. sudo pacman -U ./emacs-<pkgver>-<pkgrel>-x86_64.pkg.tar.zst

For anyone who cares, there's (at least) one case in which this patch
won't quite cut it. Right now, it assumes that in `send_process', when
`sendto' returns -1 with errno as EAGAIN or EWOULDBLOCK, it's because
there's a maxed-out buffer somewhere, presumably on account of the
sender not buying into the lock-step acknowledgment flow prescribed by
the ancient spec. But if there's a non-remote chance that it could be
something else unrelated to a non-compliant sender, that could be
problematic because a fully compliant one might end up waiting for a
receipt that never comes. Obviously, this never happens in my contrived
repro scenario. But making room for it would probably involve looking
after another timer, which I'd rather avoid if possible.

Just FYI, I've added an additional patch that you can freely ignore (it
won't apply cleanly on 27.2 anyway). Also (just for posterity), I've
updated the helper script to simulate the pedantic case as well.

0001-Display-error-message-on-incomplete-ERC-DCC-transfer.patch
Description: Text Data

0002-Don-t-send-reports-in-erc-dcc-get-filter-when-nested.patch
Description: Text Data

serve.py
Description: Binary data