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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 54458 in the body.
You can then email your comments to 54458 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Fernando de Morais <fernandodemorais.jf <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Cc: bandali <at> gnu.org
Subject: 27.2; erc-dcc-get: Re-entering top level after C stack overflow
Date: Fri, 18 Mar 2022 19:59:40 -0300

To reproduce, which is possible with 'emacs -Q' (when logged into an IRC
server and in a channel):

   /dcc get NICK FILE

   Results in:

   If FILE is larger than 120~150 MB, `erc-dcc' cannot handle the
download process. Transfers of such files causes "Re-entering top level
after C stack overflow" and, sometimes, crash.

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

   If I reduce the `max-specpdl-size', the process stop and I don't get
the file properly.


In GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.33, cairo version 1.17.4)
 of 2022-03-11 built on arojas
Windowing system distributor 'The X.Org Foundation', version 11.0.12101003
System Description: Arch Linux

Recent messages:
Mark set
Sole completion
No match [5 times]
Re-entering top level after C stack overflow [5 times]
Mark set

Configured using:
 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --with-x-toolkit=gtk3 --with-xft --with-wide-int
 --with-modules --with-cairo --with-harfbuzz 'CFLAGS=-march=x86-64
 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2
 -Wformat -Werror=format-security -fstack-clash-protection
 -fcf-protection -flto=auto'
 'LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -flto=auto''

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD JSON
PDUMPER LCMS2 GMP

Important settings:
  value of $LANG: pt_BR.UTF-8
  locale-coding-system: utf-8-unix

Major mode: ERC

Minor modes in effect:
  emojify-mode: t
  erc-services-mode: t
  erc-list-mode: t
  erc-menu-mode: t
  erc-autojoin-mode: t
  erc-ring-mode: t
  erc-networks-mode: t
  erc-pcomplete-mode: t
  erc-track-mode: t
  erc-track-minor-mode: t
  erc-match-mode: t
  erc-button-mode: t
  erc-fill-mode: t
  erc-stamp-mode: t
  erc-netsplit-mode: t
  erc-spelling-mode: t
  erc-image-mode: t
  erc-irccontrols-mode: t
  erc-noncommands-mode: t
  erc-move-to-prompt-mode: t
  erc-readonly-mode: t
  shell-dirtrack-mode: t
  flyspell-mode: (message-mode t)
  doom-modeline-mode: t
  marginalia-mode: t
  icomplete-vertical-mode: t
  icomplete-mode: t
  minibuffer-electric-default-mode: t
  minibuffer-depth-indicate-mode: t
  recentf-mode: t
  minions-mode: t
  display-battery-mode: t
  display-time-mode: t
  global-so-long-mode: t
  show-paren-mode: t
  electric-pair-mode: t
  delete-selection-mode: t
  gcmh-mode: t
  leaf-key-override-global-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  temp-buffer-resize-mode: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rfc822 mml mml-sec gnus-util
rmail rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils orderless gnutls network-stream puny nsm
rmc emojify apropos tar-mode arc-mode archive-mode ht erc-services pass
epa-file epa derived epg epg-config erc-list erc-menu erc-join erc-ring
erc-networks erc-pcomplete erc-track erc-match erc-button erc-fill
erc-stamp erc-netsplit erc-spelling erc-image image-dired image-mode
exif dired-x dired-aux dired dired-loaddefs url-queue erc-dcc
erc-goodies erc erc-backend erc-compat erc-loaddefs mule-util face-remap
disp-table checkdoc lisp-mnt page-break-lines ox-taskjuggler ox-md
ox-gemini url-util ox-odt rng-loc rng-uri rng-parse rng-match rng-dt
rng-util rng-pttrn nxml-parse nxml-ns nxml-enc xmltok nxml-util ox-latex
ox-icalendar org-agenda org-refile ox-html table ox-ascii ox-publish ox
org-element avl-tree generator ob-octave org ob ob-tangle ob-ref ob-lob
ob-table ob-exp org-macro org-footnote org-src ob-comint org-pcomplete
org-list org-faces org-entities noutline outline org-version
ob-emacs-lisp ob-core ob-eval org-table oc-basic bibtex org-keys oc
org-loaddefs find-func cal-menu calendar cal-loaddefs ol org-compat
org-macs tramp-cache tramp-sh tramp tramp-loaddefs trampver
tramp-integration files-x tramp-compat parse-time iso8601 time-date
ls-lisp format-spec vc-mtn vc-hg vc-git diff-mode easy-mmode vc-bzr
vc-src vc-sccs vc-svn vc-cvs vc-rcs vc vc-dispatcher corfu flymake-proc
flymake project compile exec-path-from-shell bash-completion shell
pcomplete comint ansi-color ring warnings display-line-numbers goto-addr
hl-line hideshow yasnippet flyspell ispell rainbow-delimiters bookmark
text-property-search pp doom-modeline doom-modeline-segments
doom-modeline-env doom-modeline-core shrink-path f s dash init ibuf-macs
marginalia icomplete-vertical icomplete minibuf-eldef mb-depth
doom-themes-ext-org doom-nord-theme pcase doom-themes doom-themes-base
dashboard dashboard-widgets all-the-icons all-the-icons-faces
data-material data-weathericons data-octicons data-fileicons
data-faicons data-alltheicons recentf tree-widget cl-extra help-mode
minions battery time so-long paren elec-pair edmacro kmacro ffap
thingatpt delsel no-littering benchmark-init advice auth-source-pass
gcmh system-packages leaf-keywords leaf finder-inf tex-site rx info
package browse-url url-handlers url-parse auth-source cl-seq eieio
eieio-core cl-macs eieio-loaddefs password-cache json subr-x map
url-vars seq byte-opt gv bytecomp byte-compile cconv cus-edit easymenu
cus-start cus-load wid-edit cl-loaddefs cl-lib early-init tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win
x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting cairo move-toolbar gtk x-toolkit
x multi-tty make-network-process emacs)

Memory information:
((conses 16 531131 442384)
 (symbols 48 39797 3)
 (strings 32 216396 31201)
 (string-bytes 1 5373142)
 (vectors 16 82004)
 (vector-slots 8 2730349 162516)
 (floats 8 1086 2685)
 (intervals 56 843 1711)
 (buffers 1000 20))

Message #8 received at 54458 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Fernando de Morais <fernandodemorais.jf <at> gmail.com>
Cc: 54458 <at> debbugs.gnu.org, bandali <at> gnu.org
Subject: Re: bug#54458: 27.2; erc-dcc-get: Re-entering top level after C
 stack overflow
Date: Mon, 21 Mar 2022 07:09:00 -0700

[Message part 1 (text/plain, inline)]

Hi Fernando,

Fernando de Morais <fernandodemorais.jf <at> gmail.com> writes:

> If FILE is larger than 120~150 MB, `erc-dcc' cannot handle the
> download process. Transfers of such files causes "Re-entering top
> level after C stack overflow" and, sometimes, crash.

Unfortunately, I was unable to reproduce the error message or the crash
using the same ArchLinux Emacs package. See attached logs.

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

I neglected to try this variant but certainly can.

> If I reduce the `max-specpdl-size', the process stop and I don't get
> the file properly.

No luck here either. I couldn't get any transfers to terminate
prematurely by lowering this value significantly.

One thing I found somewhat curious was that all the receiver's "length
acks" were clumped together in batches. These are those 4-byte messages
containing the length of the last chunk received. (The raw traffic log
only shows the first of many repeating instances.) I'd have to double
check on the protocol, but I'm guessing this is normal and thus
unrelated. If not, I can try again using a different client on the
sending side.

I also tried starving Emacs of resources to provoke some kind of related
response. While I could get it to crash during transfers, most of the
info printed ended up being metadata relevant to the supervisor (systemd
cgroups) rather than anything revealing from Emacs itself.

Anyway, since you're able to manifest this consistently, what about
seeing if any insights can be found by attaching a debugger? Not sure
what a sensible break point would be (handle_sigsegv perhaps?). As might
be obvious, I'm rather useless in this department. Hopefully an expert
will chime in at some point. Thanks.

[bookends.log (text/plain, attachment)]

[configuration.log (text/plain, attachment)]

[misc.log (text/plain, attachment)]

[pcap.log (text/plain, attachment)]

Message #13 received at 54458 <at> debbugs.gnu.org (full text, mbox):

From: Fernando de Morais <fernandodemorais.jf <at> gmail.com>
To: "J.P." <jp <at> neverwas.me>
Cc: 54458 <at> debbugs.gnu.org, bandali <at> gnu.org
Subject: Re: bug#54458: 27.2; erc-dcc-get: Re-entering top level after C
 stack overflow
Date: Tue, 22 Mar 2022 10:50:44 -0300

[Message part 1 (text/plain, inline)]

Hello J.P.,

First of all, thanks for checking my bug report.

"J.P." <jp <at> neverwas.me> writes:

> Unfortunately, I was unable to reproduce the error message or the crash
> using the same ArchLinux Emacs package. See attached logs.

Interesting! I've been experiencing this issue since I started using
ERC, a couple of years ago. However, at the same time, I'm glad to know
that it could be something on my side.

> I neglected to try this variant but certainly can.

I understand.

> No luck here either. I couldn't get any transfers to terminate
> prematurely by lowering this value significantly.

One more time, this is very interesting. In my config., that variable is
set to a value of 24000. If I lower it to the standard value, 1600, the
transfer stops, as informed earlier.

I don't know for sure but, maybe, is a problem in the sending side
client, or in the server? I am just a regular user of IRC and don't
really understand all parts of the protocol, so just guessing here.

> Anyway, since you're able to manifest this consistently, what about
> seeing if any insights can be found by attaching a debugger? Not sure
> what a sensible break point would be (handle_sigsegv perhaps?).

Well, I've never debugged an error like this, especially using GDB, but
attached are some logs that I managed to capture:

  - The ``backtrace.log'' is just the standard output that shows when
    Emacs crashes after the multiple C stack overflow messages;
  - The ``core.3183'' one is the output of the `coredumpctl info <PID>'
    command; and
  - The ``gdb_bt_emacs_core.3183.log'' one is the backtrace output from
    gdb of the previous core dump.

Unfortunately I also don't know which breakpoints to set to be more
useful.

> As might be obvious, I'm rather useless in this department. Hopefully
> an expert will chime in at some point. Thanks.

Thank you and I also hope that others can come up with ideas on how to
resolve or (best) debug this issue.

-- 
Regards,
Fernando de Morais.

[backtrace.log (text/plain, attachment)]

[core.3183 (text/plain, attachment)]

[gdb_bt_emacs_core.3183.log (text/plain, attachment)]

Message #16 received at 54458 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Fernando de Morais <fernandodemorais.jf <at> gmail.com>
Cc: 54458 <at> debbugs.gnu.org, bandali <at> gnu.org, jp <at> neverwas.me
Subject: Re: bug#54458: 27.2;
 erc-dcc-get: Re-entering top level after C stack overflow
Date: Tue, 22 Mar 2022 16:36:42 +0200

> From: Fernando de Morais <fernandodemorais.jf <at> gmail.com>
> Date: Tue, 22 Mar 2022 10:50:44 -0300
> Cc: 54458 <at> debbugs.gnu.org, bandali <at> gnu.org
> 
> Well, I've never debugged an error like this, especially using GDB, but
> attached are some logs that I managed to capture:
> 
>   - The ``backtrace.log'' is just the standard output that shows when
>     Emacs crashes after the multiple C stack overflow messages;
>   - The ``core.3183'' one is the output of the `coredumpctl info <PID>'
>     command; and
>   - The ``gdb_bt_emacs_core.3183.log'' one is the backtrace output from
>     gdb of the previous core dump.

It seems that your Emacs binary is stripped of debug symbols, so the
backtrace produced by GDB is not useful.  can you rebuild without
stripping, or download and install the missing debug symbols
somewhere?  Then repeat the experiment and post the backtrace.

Thanks.

Message #19 received at 54458 <at> debbugs.gnu.org (full text, mbox):

From: Fernando de Morais <fernandodemorais.jf <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 54458 <at> debbugs.gnu.org, bandali <at> gnu.org, jp <at> neverwas.me
Subject: Re: bug#54458: 27.2; erc-dcc-get: Re-entering top level after C
 stack overflow
Date: Sun, 27 Mar 2022 14:34:43 -0300

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

> can you rebuild without stripping, or download and install the missing
> debug symbols somewhere?  Then repeat the experiment and post the
> backtrace.
>
> Thanks.

Hello Eli,

I rebuilt Emacs from ``emacs-27'' branch, following the DEBUG guide that
came in etc folder.

I hope the logs can now be more useful.

Thanks!

-- 
Regards,
Fernando de Morais.

[backtrace.log (text/plain, attachment)]

[core.35251 (text/plain, attachment)]

[gdb_bt_emacs_core.35251.log (text/plain, attachment)]

Message #22 received at 54458 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Fernando de Morais <fernandodemorais.jf <at> gmail.com>
Cc: 54458 <at> debbugs.gnu.org, bandali <at> gnu.org, jp <at> neverwas.me
Subject: Re: bug#54458: 27.2; erc-dcc-get: Re-entering top level after C
 stack overflow
Date: Sun, 27 Mar 2022 20:56:35 +0300

> From: Fernando de Morais <fernandodemorais.jf <at> gmail.com>
> Cc: jp <at> neverwas.me,  54458 <at> debbugs.gnu.org,  bandali <at> gnu.org
> Date: Sun, 27 Mar 2022 14:34:43 -0300
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > can you rebuild without stripping, or download and install the missing
> > debug symbols somewhere?  Then repeat the experiment and post the
> > backtrace.
> >
> > Thanks.
> 
> Hello Eli,
> 
> I rebuilt Emacs from ``emacs-27'' branch, following the DEBUG guide that
> came in etc folder.
> 
> I hope the logs can now be more useful.

Thanks.  This surely looks like either infinite recursion, or a very
deep recursion that triggers GC, and GC exhausts the stack (since GC
itself is deeply recursive).

It would help if you could reproduce the problem again, this time when
running Emacs under GDB to begin with.  When Emacs segfaults, please
do

  (gdb) source /path/to/emacs/src/.gdbinit
  (gdb) xbacktrace

(replace /path/to/emacs/src with the directory where you have the
Emacs source tree).  The last command will show the Lisp interpreter
nacktrace, which will make it easier to understand where the recursion
happens in Lisp.

Message #25 received at 54458 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Fernando de Morais <fernandodemorais.jf <at> gmail.com>
Cc: 54458 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, bandali <at> gnu.org,
 jp <at> neverwas.me
Subject: bug#54458: 27.2; erc-dcc-get: Re-entering top level after C stack
 overflow
Date: Sun, 27 Mar 2022 22:54:10 +0200

> I hope the logs can now be more useful.

Very useful! If I'm reading the stack trace right then someone should tell ERC not to send data from a process filter function:

(process-send-string)
-> send_process
; output buffer is full, so we try reading data to unclog it
-> wait_reading_process_output
-> { some filter function }
-> (process-send-string)  ; again, and round it goes...

Not sure where this happens but it looks like it might be erc-dcc-send-filter.

Message #28 received at 54458 <at> debbugs.gnu.org (full text, mbox):

From: Fernando de Morais <fernandodemorais.jf <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 54458 <at> debbugs.gnu.org, bandali <at> gnu.org, jp <at> neverwas.me
Subject: Re: bug#54458: 27.2; erc-dcc-get: Re-entering top level after C
 stack overflow
Date: Sun, 27 Mar 2022 19:09:16 -0300

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

> It would help if you could reproduce the problem again, this time when
> running Emacs under GDB to begin with.  When Emacs segfaults, please
> do
>
>   (gdb) source /path/to/emacs/src/.gdbinit
>   (gdb) xbacktrace
>
> (replace /path/to/emacs/src with the directory where you have the
> Emacs source tree).  The last command will show the Lisp interpreter
> nacktrace, which will make it easier to understand where the recursion
> happens in Lisp.

Right!

I don't know if something is missing here in my build, but when I
reproduced the problem and source the .gdbinit file, as well as calling
`xbacktrace', only one line appeared as output, as can be seen in the
attached log:

    Cannot access memory at address 0x7fffff66ff4

Just in case, I saved the complete GDB log, from `run' to `xbacktrace'.

Hope it helps.

-- 
Regards,
Fernando de Morais.

[gdb_output.log (text/plain, attachment)]

Message #31 received at 54458 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Fernando de Morais <fernandodemorais.jf <at> gmail.com>
Cc: 54458 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, bandali <at> gnu.org,
 jp <at> neverwas.me
Subject: Re: bug#54458: 27.2; erc-dcc-get: Re-entering top level after C stack
 overflow
Date: Mon, 28 Mar 2022 11:23:09 +0200

27 mars 2022 kl. 22.54 skrev Mattias Engdegård <mattiase <at> acm.org>:

> Not sure where this happens but it looks like it might be erc-dcc-send-filter.

Some additional notes:

This is not an infinite recursion; eventually the stack will culminate and recede, unless (as in this case) we run out of room first.

In Emacs 29 the byte-code engine is more stack-efficient but that just means that bigger files can be transferred without a stack overflow. The bug is still there.

Presumably we should add a note to the documentation of process filter functions that they shouldn't be used to send more data to the process. (Not sure what to recommend, an idle timer maybe?)

I'm not going to fix this because I don't know ERC very well and wouldn't be able to test it sufficiently, but our ERC maintainers do and can!

Message #34 received at 54458 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: fernandodemorais.jf <at> gmail.com, jp <at> neverwas.me, bandali <at> gnu.org,
 54458 <at> debbugs.gnu.org
Subject: Re: bug#54458: 27.2; erc-dcc-get: Re-entering top level after C stack
 overflow
Date: Mon, 28 Mar 2022 14:14:55 +0300

> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Mon, 28 Mar 2022 11:23:09 +0200
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 54458 <at> debbugs.gnu.org, bandali <at> gnu.org,
>         jp <at> neverwas.me
> 
> In Emacs 29 the byte-code engine is more stack-efficient but that just means that bigger files can be transferred without a stack overflow. The bug is still there.

There will always be ways of making Emacs run out of C stack space,
with a sufficiently ... ehm ... sophisticated program.  There's no way
around that, as long as the OS places a limit on the runtime stack.

> Presumably we should add a note to the documentation of process filter functions that they shouldn't be used to send more data to the process.

Yes, please.  With an explicit caveat that it could cause stack
overflow.

> (Not sure what to recommend, an idle timer maybe?)

Yes.  IOW, design change.

> I'm not going to fix this because I don't know ERC very well and wouldn't be able to test it sufficiently, but our ERC maintainers do and can!

Hopefully, yes.

Message #37 received at 54458 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Mattias Engdegård <mattiase <at> acm.org>, bandali <at> gnu.org,
 54458 <at> debbugs.gnu.org, fernandodemorais.jf <at> gmail.com
Subject: Re: bug#54458: 27.2; erc-dcc-get: Re-entering top level after C
 stack overflow
Date: Mon, 28 Mar 2022 05:08:56 -0700

[Message part 1 (text/plain, inline)]

Hi Mattias (and Eli),

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

> 27 mars 2022 kl. 22.54 skrev Mattias Engdegård <mattiase <at> acm.org>:
>
>> Not sure where this happens but it looks like it might be erc-dcc-send-filter.
>
> Presumably we should add a note to the documentation of process filter
> functions that they shouldn't be used to send more data to the process. (Not
> sure what to recommend, an idle timer maybe?)

As you highlighted up thread, inhibited sends appeal to
`wait_reading_process_output' to try and shake something loose. I agree
such occasions seem likeliest to trigger "unexpected" filter nesting.

As far as best practices go, I'm not sure how a successful
request-response dialog can happen without participants being able to
react in a timely fashion. If the main worry is stack growth, then
perhaps scheduling something on the event loop with a timer (as you say)
makes the most sense.

I actually tried that (via `run-at-time') in the tinkering detailed
below but still managed to incur "error running timer" messages that
referred to "excessive variable binding." Should I have used something
in the "idle" department instead?

The approach that seemed to "work" mimics the one relied on by ERC's
main client filter, which takes pains to ensure overlapping calls merely
stash the input and bail (via `erc-server-processing-p'). Perhaps a
synchronization primitive especially suited to process filters would
make more sense? (No idea.)

> I'm not going to fix this because I don't know ERC very well and wouldn't be
> able to test it sufficiently, but our ERC maintainers do and can!

You're very generous, and your expertise is much appreciated. (But as
Eli says, "hopefully".)


                              . . .

Hi Fernando,

I've managed to trigger behavior (somewhat) resembling what you've
described. It's quite possible, even likely, that this is total baloney,
but please humor me anyway this one round (unless you spot something
totally egregious, that is). The basic "hypothesis" seems to comport
with Mattias's analysis. It posits that the peer you're connecting to is
misbehaving and engaged in some combination of:

 1. not reading frequently enough amid sends

 2. being too stingy with its read buffer

I'd be great if you could confirm this suspicion by checking if the
"window" portion of the TCP ACK segments containing actual payloads go
to zero after a spell. This can be done with tcpdump or wireshark. A
well behaved peer respecting the protocol should normally have nonzero
windows throughout.

On the client side (Emacs master this time), here is what I observe
after following the steps enumerated further down: There appears to be
another buffer of around 64KB that needs filling before I (the receiver)
encounter the error, which in my case is a "variable binding depth
exceeds max-specpdl-size" message along with an unresponsive UI. For me,
this happens without fail at around 800MB after the TCP window goes to 0
(at around 100MB). Strangely, increasing the value of `max-specpdl-size'
doesn't change things perceptively.

Anyway, the file-writing operation continues for around 200MB and
eventually peters out. But the connection only dies after the sender
closes it normally (having sent everything). The IRC connection of
course PINGs out and is severed by the IRC server. The Emacs receiver
process eventually recovers responsiveness (if you wait long enough).

These are the steps I followed. They require two emacs -Q instances, a
server, and the attached script:

 1. connect to the server and make sure the sender can /whois the
    receiver (have them join the same #chan if necessary)
 
 2. start the script:

    python ./script.py ./some_large_file.bin misbehave
 
 3. on the sender:

    /msg RecvNick ^ADCC SEND some_large_file.bin 2130706433 9899 1234567890^A

    where 1234567890 is the size of the file in bytes and ^A is an
    actual control char
 
 4. on the receiver:

    /dcc get SendNick some_large_file.bin

As mentioned earlier, I've attached a crude experiment (patch) that just
records whether we're currently sending (so receipts can be skipped when
the flag is set). I used the process plist for now, but erc-dcc does
keep a global context-state object called `erc-dcc-entry-data', which I
suppose may be more fitting. The idea is to roll with the punches from a
pathological peer but also (of course) interoperate correctly with an
obedient, protocol-abiding one.

Normal sender
- Sends 1405135128 bytes
- Sees 343051 reports

Aberrant sender
- Sends 1405135128 bytes
- Ignores 238662 + unknown reports

Let me know if anything needs clarifying. And thanks for your patience!

[serve.py (application/octet-stream, attachment)]

[0001-EXPERIMENT-regulate-ACK-updates-in-erc-dcc-get-filte.patch (text/x-patch, attachment)]

Message #40 received at 54458 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: "J.P." <jp <at> neverwas.me>
Cc: fernandodemorais.jf <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>,
 bandali <at> gnu.org, 54458 <at> debbugs.gnu.org
Subject: Re: bug#54458: 27.2; erc-dcc-get: Re-entering top level after C stack
 overflow
Date: Tue, 29 Mar 2022 17:49:05 +0200

[Message part 1 (text/plain, inline)]

28 mars 2022 kl. 14.08 skrev J.P. <jp <at> neverwas.me>:

> As you highlighted up thread, inhibited sends appeal to
> `wait_reading_process_output' to try and shake something loose. I agree
> such occasions seem likeliest to trigger "unexpected" filter nesting.

Although it seems reasonable to require that filter functions abstain from sending more data to the process, there may be another way: preventing re-entering process-send calls from recursing further.

Attached is a proof of concept: if process-send calls are invoked when another activation already exists, just enqueue the data and let the previous activation deal with the actual transmission. That nips the recursion in the buds.

The principle seems sound but if anyone can think of problems with the approach, please do tell.

Of course, one reason to make the change in ERC is that it would fix the problem in all Emacs versions, not just 29.

[send-process-nesting.diff (application/octet-stream, attachment)]

[Message part 3 (text/plain, inline)]

Message #43 received at 54458 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: fernandodemorais.jf <at> gmail.com, bandali <at> gnu.org, 54458 <at> debbugs.gnu.org,
 jp <at> neverwas.me
Subject: Re: bug#54458: 27.2; erc-dcc-get: Re-entering top level after C stack
 overflow
Date: Tue, 29 Mar 2022 19:45:28 +0300

> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Tue, 29 Mar 2022 17:49:05 +0200
> Cc: Eli Zaretskii <eliz <at> gnu.org>, fernandodemorais.jf <at> gmail.com,
>         54458 <at> debbugs.gnu.org, bandali <at> gnu.org
> 
> Although it seems reasonable to require that filter functions abstain from sending more data to the process, there may be another way: preventing re-entering process-send calls from recursing further.
> 
> Attached is a proof of concept: if process-send calls are invoked when another activation already exists, just enqueue the data and let the previous activation deal with the actual transmission. That nips the recursion in the buds.
> 
> The principle seems sound but if anyone can think of problems with the approach, please do tell.

I think this should be conditioned on the same process being used, no?
Doing this for two different processes doesn't cause problems, does
it?  If it does, can you describe in more detail how the recursion
happens?

Thanks.

Message #46 received at 54458 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: fernandodemorais.jf <at> gmail.com, bandali <at> gnu.org, 54458 <at> debbugs.gnu.org,
 jp <at> neverwas.me
Subject: Re: bug#54458: 27.2; erc-dcc-get: Re-entering top level after C stack
 overflow
Date: Tue, 29 Mar 2022 19:47:52 +0200

[Message part 1 (text/plain, inline)]

29 mars 2022 kl. 18.45 skrev Eli Zaretskii <eliz <at> gnu.org>:

> I think this should be conditioned on the same process being used, no?

Oh, yes, that's clearly a valid objection. New attempt attached.

[send-process-nesting.diff (application/octet-stream, attachment)]

Message #49 received at 54458 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: fernandodemorais.jf <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>,
 bandali <at> gnu.org, 54458 <at> debbugs.gnu.org
Subject: Re: bug#54458: 27.2; erc-dcc-get: Re-entering top level after C
 stack overflow
Date: Tue, 29 Mar 2022 12:44:34 -0700

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

> Although it seems reasonable to require that filter functions abstain
> from sending more data to the process,

I think "app makers" (those of us building on Emacs as a platform) need
a solid, authoritative pattern to mimic. What we at ERC are trying with
our test server is to invert this "reactor pattern" by limiting the role
of the filter to that of "reconstitutor of application frames." When one
or more complete protocol frames arrives (in our case, CRLF delimited),
it enqueues them and returns, perhaps after stashing any residual bytes
for the next invocation. [1]

Then, concurrently, we have our main handler/dispatcher loop, which is
started by a specific sentinel event. It peeks at the queue and then
maybe dispatches a method/reply handler or maybe handles housekeeping
instead. The key for app makers, I think, is that we regain control by
being free to deal with complete messages (remote "method calls" or
"return values," logically) at a time and place of our choosing, rather
than being forced to the dance to the tune of the selector.

> there may be another way: preventing re-entering process-send calls
> from recursing further.
>
> Attached is a proof of concept: if process-send calls are invoked when
> another activation already exists, just enqueue the data and let the
> previous activation deal with the actual transmission. That nips the
> recursion in the buds.

This seems an ingenious way of helping problematic code that already
exists. I'll give it a whirl just for fun. (But alas, I know nothing.)

> Of course, one reason to make the change in ERC is that it would fix the
> problem in all Emacs versions, not just 29.

You mean make the change by abstaining from the antipattern, right? I
think ERC has no choice but to do just that because we're an ELPA
package supporting multiple versions of Emacs.

[1] https://git.neverwas.me/repos/erc-v3/tree/test/erc-d/erc-d.el?id=f1af52#n442

Message #52 received at 54458 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: fernandodemorais.jf <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>,
 emacs-erc <at> gnu.org, bandali <at> gnu.org, 54458 <at> debbugs.gnu.org
Subject: Re: bug#54458: 27.2; erc-dcc-get: Re-entering top level after C
 stack overflow
Date: Tue, 29 Mar 2022 21:02:44 -0700

"J.P." <jp <at> neverwas.me> writes:

> Mattias Engdegård <mattiase <at> acm.org> writes:
>
>> Attached is a proof of concept: if process-send calls are invoked when
>> another activation already exists, just enqueue the data and let the
>> previous activation deal with the actual transmission. That nips the
>> recursion in the buds.
>
> This seems an ingenious way of helping problematic code that already
> exists. I'll give it a whirl just for fun. (But alas, I know nothing.)

FWIW, I ran ERC's I/O heavy test suite (not yet part of Emacs) against
these changes, and it passed. I also tried them out on that quasi-repro
recipe (the one with the python script), and the problem vanished
transparently, as expected.

BTW (cc. Fernando), the reason I simply dropped nested send attempts in
that earlier patch was because their payloads (those 4-byte receipts)
are only meaningful to a sender honoring "the spec" [1], which says

  The sender should not continue to transmit until the recipient has
  acknowledged all data already transmitted.

IOW, there shouldn't be prohibitive wire pressure when dealing with an
obedient sender, so we needn't worry about an outgoing receipt being
dropped (right?). And for corner-cutting senders, either those just
treating receipts as heartbeats and ignoring their contents or those
never bothering to read from the socket at all, "sparse but strictly
increasing" should always suffice, I think. If I'm wrong on either
count, we can always add more complexity.

QUICK ADMINISTRATIVE NOTE: this whole time, I've been neglecting to Cc
the emacs-erc mailing list (a lapse in professionalism on my part). So
for anyone replying up thread, please cc. emacs-erc <at> gnu.org, if you
happen to remember. Thanks.

[1] https://www.irchelp.org/protocol/ctcpspec.html

Message #55 received at 54458 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: "J.P." <jp <at> neverwas.me>
Cc: Fernando de Morais <fernandodemorais.jf <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>, emacs-erc <at> gnu.org, bandali <at> gnu.org,
 54458 <at> debbugs.gnu.org
Subject: Re: bug#54458: 27.2; erc-dcc-get: Re-entering top level after C stack
 overflow
Date: Wed, 30 Mar 2022 17:28:37 +0200

30 mars 2022 kl. 06.02 skrev J.P. <jp <at> neverwas.me>:

> FWIW, I ran ERC's I/O heavy test suite (not yet part of Emacs) against
> these changes, and it passed. I also tried them out on that quasi-repro
> recipe (the one with the python script), and the problem vanished
> transparently, as expected.

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.

Message #58 received at 54458 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Mattias Engdegård <mattiase <at> acm.org>, Fernando de Morais
 <fernandodemorais.jf <at> gmail.com>
Cc: 54458 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, emacs-erc <at> gnu.org,
 bandali <at> gnu.org
Subject: Re: bug#54458: 27.2; erc-dcc-get: Re-entering top level after C
 stack overflow
Date: Thu, 31 Mar 2022 12:18:04 -0700

[Message part 1 (text/plain, inline)]

Mattias Engdegård <mattiase <at> 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 (text/x-patch, attachment)]

[0002-Don-t-send-reports-in-erc-dcc-get-filter-when-nested.patch (text/x-patch, attachment)]

[serve.py (application/octet-stream, attachment)]

Message #61 received at 54458 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: 54458 <at> debbugs.gnu.org
Cc: fernandodemorais.jf <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>,
 emacs-erc <at> gnu.org, bandali <at> gnu.org,
 Mattias Engdegård <mattiase <at> acm.org>
Subject: Re: bug#54458: 27.2; erc-dcc-get: Re-entering top level after C
 stack overflow
Date: Thu, 31 Mar 2022 23:32:12 -0700

"J.P." <jp <at> neverwas.me> writes:

> BTW (cc. Fernando), the reason I simply dropped nested send attempts in
> that earlier patch was because their payloads (those 4-byte receipts)
> are only meaningful to a sender honoring "the spec" [1], which says
>
>   The sender should not continue to transmit until the recipient has
>   acknowledged all data already transmitted.
>
> IOW, there shouldn't be prohibitive wire pressure when dealing with an
> obedient sender, so we needn't worry about an outgoing receipt being
> dropped (right?). And for corner-cutting senders, either those just
> treating receipts as heartbeats and ignoring their contents or those
> never bothering to read from the socket at all, "sparse but strictly
> increasing" should always suffice, I think. If I'm wrong on either
> count, we can always add more complexity.

A quick note regarding the proposed implementation: the Qt-based
graphical client KVIrc (free software) takes an identical tack WRT
dropping instead of retrying denied sends.

From DccRecvThread::sendAck in src/modules/dcc/DccFileTransfer.cpp [1]:

  iRet = kvi_socket_send(m_fd, (void *)(ack), ackSize);

  if(iRet == ackSize)
     return true; // everything sent

  // When downloading from a fast server using send-ahead via an
  // asymmetric link (such as the common ADSL lines) it may happen that
  // the network output queue gets saturated with ACKs. In this case the
  // network stack will refuse to send our packet and we get here.

  // We should either retry to send the ACK in a while or avoid sending
  // it at all (as with send-ahead acks aren't usually checked
  // per-packet).

  if(iRet == 0)
  {
     // We can live with this: no data has been sent at all
     // Not sending the ack and hoping that the server will not
     // stall is better than killing the connection from our side
     // anyway.
     return true;
  }

  if(iRet < 0)
  {
  // Reported error. If it's EAGAIN or EINTR then no data has been sent.

  [...]

  if((err != EAGAIN) && (err != EINTR))
  #endif //!(defined(COMPILE_ON_WINDOWS) || defined(COMPILE_ON_MINGW))
  	{
  	   // some other kind of error
  	   postErrorEvent(KviError::AcknowledgeError);
       return false;
  	}

    return true; // no data sent: same as iRet == 0 above.
  }

So if we stick to this approach and it turns out to be inadequate, at
least we won't be alone in having fumbled.

[1] https://github.com/kvirc/KVIrc/blob/e4a34cb9/src/modules/dcc/DccFileTransfer.cpp#L115

Message #64 received at 54458 <at> debbugs.gnu.org (full text, mbox):

From: Fernando de Morais <fernandodemorais.jf <at> gmail.com>
To: "J.P." <jp <at> neverwas.me>
Cc: Mattias Engdegård <mattiase <at> acm.org>,
 Eli Zaretskii <eliz <at> gnu.org>, emacs-erc <at> gnu.org, bandali <at> gnu.org,
 54458 <at> debbugs.gnu.org
Subject: Re: bug#54458: 27.2; erc-dcc-get: Re-entering top level after C
 stack overflow
Date: Sun, 03 Apr 2022 14:20:47 -0300

"J.P." <jp <at> neverwas.me> writes:

> 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:

Hello J.P.,

Sorry for the late response.

I applied your latest patch (0002) and file transfers larger than
120~150 MB, as well as much larger ones, completed successfully!

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.

Other than that, transfers go as expected.

Thank you! I'll be using this patched version of `erc-dcc-get-filter'.

···

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

> Very useful! If I'm reading the stack trace right then someone should
> tell ERC not to send data from a process filter function:

Hi Mattias,

Thank you too, and just like J.P. wrote in his previous message, your
observations have been fundamental to solving the problem!

-- 
Regards,
Fernando de Morais.

Message #67 received at 54458 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Fernando de Morais <fernandodemorais.jf <at> gmail.com>
Cc: Mattias Engdegård <mattiase <at> acm.org>,
 Eli Zaretskii <eliz <at> gnu.org>, emacs-erc <at> gnu.org, bandali <at> gnu.org,
 54458 <at> debbugs.gnu.org
Subject: Re: bug#54458: 27.2; erc-dcc-get: Re-entering top level after C
 stack overflow
Date: Sun, 03 Apr 2022 12:46:06 -0700

Fernando de Morais <fernandodemorais.jf <at> gmail.com> writes:

> Sorry for the late response.

Not at all. If anything's late, it's our addressing this after decades.

> I applied your latest patch (0002) and file transfers larger than
> 120~150 MB, as well as much larger ones, completed successfully!
>
> 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.

Neither of those sounds particularly pleasant. In fact, they sound like
regressions. So, just to clarify:

 - Before the proposed patch, simultaneous transfers were possible, and
   now they're not.

 - Before this patch, unresponsiveness wasn't a thing (crashing and
   scary messages aside), but now it is.

I'll admit to callously not even considering the first, and I might have
trouble reproducing the second but will certainly give it a go.

> Other than that, transfers go as expected.
>
> Thank you! I'll be using this patched version of `erc-dcc-get-filter'.

You're welcome, but hopefully we™ can do better (amid tackling ERC's
rather pressing, even borderline existential problems).

Message #70 received at 54458 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Fernando de Morais <fernandodemorais.jf <at> gmail.com>
Cc: Mattias Engdegård <mattiase <at> acm.org>,
 Eli Zaretskii <eliz <at> gnu.org>, emacs-erc <at> gnu.org, bandali <at> gnu.org,
 54458 <at> debbugs.gnu.org
Subject: Re: bug#54458: 27.2; erc-dcc-get: Re-entering top level after C
 stack overflow
Date: Sun, 10 Apr 2022 14:31:33 -0700

[Message part 1 (text/plain, inline)]

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 (text/x-patch, attachment)]

[serve.py (application/octet-stream, attachment)]

Message #73 received at 54458 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Fernando de Morais <fernandodemorais.jf <at> gmail.com>
Cc: Mattias Engdegård <mattiase <at> acm.org>,
 Eli Zaretskii <eliz <at> gnu.org>, emacs-erc <at> gnu.org, bandali <at> gnu.org,
 54458 <at> debbugs.gnu.org
Subject: Re: bug#54458: 27.2; erc-dcc-get: Re-entering top level after C
 stack overflow
Date: Sun, 10 Apr 2022 20:17:35 -0700

[Message part 1 (text/plain, inline)]

Hi Fernando,

Another possibility I've been kicking around is (optionally) running DCC
GET operations in a subprocess. Attached is a POC (patch #4), which I'm
hoping you'll try. Unfortunately, like patch #2, I believe it'll only
apply cleanly on newer Emacs versions. (You'll also be needing to set
the option `erc-dcc-get-use-subprocess' to t.) Depending on the outcome
of your pcap experiment, this (or some improved version) may be our only
practical way forward. Thanks.

[0000-v2-v3.diff (text/x-patch, attachment)]

[0001-Display-error-message-on-incomplete-ERC-DCC-transfer.patch (text/x-patch, attachment)]

[0002-Don-t-send-reports-in-erc-dcc-get-filter-when-nested.patch (text/x-patch, attachment)]

[0003-Allow-matching-against-string-values-in-erc-dcc-memb.patch (text/x-patch, attachment)]

[0004-Allow-running-erc-dcc-GET-operations-in-a-subprocess.patch (text/x-patch, attachment)]

Message #76 received at 54458 <at> debbugs.gnu.org (full text, mbox):

From: Fernando de Morais <fernandodemorais.jf <at> gmail.com>
To: "J.P." <jp <at> neverwas.me>
Cc: Mattias Engdegård <mattiase <at> acm.org>,
 Eli Zaretskii <eliz <at> gnu.org>, emacs-erc <at> gnu.org, bandali <at> gnu.org,
 54458 <at> debbugs.gnu.org
Subject: Re: bug#54458: 27.2; erc-dcc-get: Re-entering top level after C
 stack overflow
Date: Sun, 24 Apr 2022 21:59:27 -0300

Hello J.P.,

Once more, sorry for the late response.

"J.P." <jp <at> neverwas.me> writes:

>> Did you mean successively or simultaneously? Because when attempting
>> the latter, I can't even get off the ground.

Precisely! My problem was in the simultaneous transfers.

>> When you get a chance, please try the proposed multi-file fix, even
>> though it does nothing for the unresponsiveness problem.

I tested your patch (0003) and it worked the way you detailed: now I can
do more than one transfer simultaneously, however, at some point I lose
control of Emacs and regain it, completely, only when the transfers are
finished.

>> Also, if it's not too much trouble, would you mind doing something
>> like

Not trouble at all! But, unfortunately, I believe I did something wrong
when running `tcpdump' command, as it did not detect any files
transferred through DCC GET in my tests and the dump file generated was
always the same, 24 bytes, containing only one line.

My command was the same as yours (as root):

   # tcpdump -i <my-interface> -Uw ./dump 'host <my-host-ip> and tcp port <erc-tls-port>'

Is there anything else that I need to do/know about this command to
generate the desired dump for you?

> Another possibility I've been kicking around is (optionally) running
> DCC GET operations in a subprocess. Attached is a POC (patch #4),
> which I'm hoping you'll try. Unfortunately, like patch #2, I believe
> it'll only apply cleanly on newer Emacs versions. (You'll also be
> needing to set the option `erc-dcc-get-use-subprocess' to t.)

I found this approach very interesting and as soon as I could I tried to
test it, but even in Emacs 28.1 I get the following error messages:

   error in process sentinel: erc-format-message: No format spec for message dcc-get-failed
   error in process sentinel: No format spec for message dcc-get-failed

Is this an issue specific to the versions of Emacs (27.2 and 28.1) I
tested it on?

Thank you so much for keeping investigating possible solutions. I'll be
using your patches #2 and #3.

-- 
Regards,
Fernando de Morais.

Message #79 received at 54458 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Fernando de Morais <fernandodemorais.jf <at> gmail.com>
Cc: Mattias Engdegård <mattiase <at> acm.org>,
 Eli Zaretskii <eliz <at> gnu.org>, emacs-erc <at> gnu.org, bandali <at> gnu.org,
 54458 <at> debbugs.gnu.org
Subject: Re: bug#54458: 27.2; erc-dcc-get: Re-entering top level after C
 stack overflow
Date: Mon, 25 Apr 2022 05:08:52 -0700

Fernando de Morais <fernandodemorais.jf <at> gmail.com> writes:

> Once more, sorry for the late response.

Not a problem! Plenty to do around here.

> I tested your patch (0003) and it worked the way you detailed: now I can
> do more than one transfer simultaneously, however, at some point I lose
> control of Emacs and regain it, completely, only when the transfers are
> finished.

I "believe" the simultaneous-receive problem and the loss-of-control
issue are unrelated (despite the second being exacerbated by the first).

> I believe I did something wrong when running `tcpdump' command, as it
> did not detect any files transferred through DCC GET in my tests and
> the dump file generated was always the same, 24 bytes, containing only
> one line.

No worries. I'll just assume the sender is behaving aberrantly. The
thing is, I still haven't been able to repro this with a real client as
sender. And when I asked around to see if anyone else has encountered
anything related, e.g.,

1. senders that never read
2. clients that always act defensively

I only got crickets for the second and for the first was told there's a
variant of the protocol (or some extension) called TSEND, which might be
to blame if enabled by a sender.

That said, I don't see an obvious problem with applying some version of
the proposed patches because we wouldn't be impacting routine behavior,
AFAICT. And since DCC has basically been deprecated for years, the risk
of incurring related hate mail is low should this observation prove
faulty.

> I found this approach very interesting and as soon as I could I tried to
> test it, but even in Emacs 28.1 I get the following error messages:
>
>    error in process sentinel: erc-format-message: No format spec for message dcc-get-failed
>    error in process sentinel: No format spec for message dcc-get-failed
>
> Is this an issue specific to the versions of Emacs (27.2 and 28.1) I
> tested it on?

Hm. And you applied *all* the patches as a sequence? I.e.,

  git am ~/somedir/000{1..4}-*.patch

Because the format spec lives in the first one:

  0001-Display-error-message-on-incomplete-ERC-DCC-transfer.patch

So that needs to be present (as do the rest). IOW, in this capacity,
they're acting as a set (not v1..vN iterations). Can you compare your
version of erc-dcc.el to the one on HEAD? BTW, I know for sure that they
won't apply cleanly on 27 (but they "should" on 28).

> Thank you so much for keeping investigating possible solutions. I'll be
> using your patches #2 and #3.

My pleasure! Thanks for reporting this. (FWIW, the subprocess thing
worked for me, but YMMV.)

Message #82 received at 54458 <at> debbugs.gnu.org (full text, mbox):

From: Fernando de Morais <fernandodemorais.jf <at> gmail.com>
To: "J.P." <jp <at> neverwas.me>
Cc: Mattias Engdegård <mattiase <at> acm.org>,
 Eli Zaretskii <eliz <at> gnu.org>, emacs-erc <at> gnu.org, bandali <at> gnu.org,
 54458 <at> debbugs.gnu.org
Subject: Re: bug#54458: 27.2; erc-dcc-get: Re-entering top level after C
 stack overflow
Date: Fri, 29 Apr 2022 11:51:13 -0300

Hello J.P.,

"J.P." <jp <at> neverwas.me> writes:

> Hm. And you applied *all* the patches as a sequence?

Last time I didn't apply them all, but this time I did. Now I'm using
Emacs 28.1, so I believe the compatibility will no longer be an issue.

Unfortunately, however, I couldn't use DCC GET when
`erc-dcc-get-use-subprocess' is t. The transfer fails and a message like
this appears:

     *** DCC: file <file_name>
         transfer failed at 0 of <file-size> in 0 seconds

In this scenario, I tried to receive files from another sender (on the
same server), but the same thing happened.

The rest of your proposed improvements work normally, as previously
reported, as long as `erc-dcc-get-use-subprocess' is nil.

-- 
Regards,
Fernando de Morais.

Message #85 received at 54458 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Fernando de Morais <fernandodemorais.jf <at> gmail.com>
Cc: Mattias Engdegård <mattiase <at> acm.org>,
 Eli Zaretskii <eliz <at> gnu.org>, emacs-erc <at> gnu.org, bandali <at> gnu.org,
 54458 <at> debbugs.gnu.org
Subject: Re: bug#54458: 27.2; erc-dcc-get: Re-entering top level after C
 stack overflow
Date: Sat, 30 Apr 2022 06:39:21 -0700

[Message part 1 (text/plain, inline)]

Hi Fernando,

Fernando de Morais <fernandodemorais.jf <at> gmail.com> writes:

> Unfortunately, however, I couldn't use DCC GET when
> `erc-dcc-get-use-subprocess' is t. The transfer fails and a message like
> this appears:
>
>      *** DCC: file <file_name>
>          transfer failed at 0 of <file-size> in 0 seconds
>
> In this scenario, I tried to receive files from another sender (on the
> same server), but the same thing happened.

Sorry about that. I shouldn't have asked you to try those patches. That
whole idea was half-baked and the execution super shoddy.

And on that note, please try these patches! I've abandoned the
subprocess stuff and am instead introducing a simple flag that inhibits
all reporting. A user can set it explicitly, or it can be activated
automatically when something nonstandard (but specific) is detected.

If you're willing, please try receiving once as you normally would. But
if the loss of control persists, try issuing a

  /dcc get -t sender file

on the next go around. Thanks for your patience!

[0000-v3-v4.diff (text/x-patch, attachment)]

[0001-Display-error-message-on-incomplete-ERC-DCC-transfer.patch (text/x-patch, attachment)]

[0002-Don-t-send-reports-in-erc-dcc-get-filter-when-nested.patch (text/x-patch, attachment)]

[0003-Allow-matching-against-string-values-in-erc-dcc-memb.patch (text/x-patch, attachment)]

[0004-Accept-turbo-param-in-erc-dcc-do-GET-command.patch (text/x-patch, attachment)]

Message #88 received at 54458 <at> debbugs.gnu.org (full text, mbox):

From: Fernando de Morais <fernandodemorais.jf <at> gmail.com>
To: "J.P." <jp <at> neverwas.me>
Cc: Mattias Engdegård <mattiase <at> acm.org>,
 Eli Zaretskii <eliz <at> gnu.org>, emacs-erc <at> gnu.org, bandali <at> gnu.org,
 54458 <at> debbugs.gnu.org
Subject: Re: bug#54458: 27.2; erc-dcc-get: Re-entering top level after C
 stack overflow
Date: Wed, 04 May 2022 10:03:12 -0300

Hello J.P.,

"J.P." <jp <at> neverwas.me> writes:

> Sorry about that. I shouldn't have asked you to try those patches. That
> whole idea was half-baked and the execution super shoddy.

Don't worry. It's been great to test these new ideas on the ERC. In
addition, they have solved the main problem that I had been facing with
the use of the client.

> If you're willing, please try receiving once as you normally would. But
> if the loss of control persists, try issuing a
>
>   /dcc get -t sender file
>
> on the next go around. Thanks for your patience!

It worked great! I was able to download four packages simultaneously,
making use of the `-t' flag, without losing control of Emacs.

In fact, the loss of control still happened a few times, even using the
flag, but for a short time and much more rarely compared to the transfer
without the flag (whose loss of control happens in, practically, every
transfer).

Thanks!

-- 
Regards,
Fernando de Morais.

Message #91 received at 54458 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Fernando de Morais <fernandodemorais.jf <at> gmail.com>
Cc: Mattias Engdegård <mattiase <at> acm.org>,
 Eli Zaretskii <eliz <at> gnu.org>, emacs-erc <at> gnu.org, bandali <at> gnu.org,
 54458 <at> debbugs.gnu.org
Subject: Re: bug#54458: 27.2; erc-dcc-get: Re-entering top level after C
 stack overflow
Date: Fri, 06 May 2022 06:06:15 -0700

[Message part 1 (text/plain, inline)]

Hi Fernando,

Fernando de Morais <fernandodemorais.jf <at> gmail.com> writes:

> It worked great! I was able to download four packages simultaneously,
> making use of the `-t' flag, without losing control of Emacs.
>
> In fact, the loss of control still happened a few times, even using the
> flag, but for a short time and much more rarely

Hm. I'm not sure what all we can do about the stuttering. The flag
inhibits all sending, so the filter is merely appending arriving bytes
to the work buffer and flushing it whenever its size crosses some
threshold. IOW, the EAGAIN loop discussed up thread can't occur. So,
whatever's causing the intermittent loss must be related to normal,
interleaved reading by those filters.

And without more insight into what's going on precisely with your
inputs, I don't think there's a whole lot we can do beyond speculate.
So, in the end, I guess I'm just asking you to suffer the status quo on
this one.

> [...] compared to the transfer without the flag (whose loss of control
> happens in, practically, every transfer).

Right. The sans-flag thing was another dumb idea you should have been
spared. In truth, it never stood a chance (I've come to learn) because
no one has ever implemented that form of TSEND. However, I've added
detection for one form that does exist and is very much in use, at least
by KVirc folk. I've also added a slight tweak for improved interop with
WeeChat, which has its own form of turbo (called "fast mode" or
something) that only requires a final ACK.

If you're able to try these, great. If not, no worries. I'll leave them
for a bit anyhow to focus on our main initiatives. Thanks for bearing
with me all these weeks (and with ERC all these years)!

J.P.

P.S (unrelated) I've also added SSEND detection (and an -s flag) for
senders that support it (it's just TLS, really).

[0000-v4-v5.diff (text/x-patch, attachment)]

[0001-Display-error-message-on-incomplete-ERC-DCC-transfer.patch (text/x-patch, attachment)]

[0002-Don-t-send-reports-in-erc-dcc-get-filter-when-nested.patch (text/x-patch, attachment)]

[0003-Allow-matching-against-string-values-in-erc-dcc-memb.patch (text/x-patch, attachment)]

[0004-Accept-turbo-param-in-erc-dcc-do-GET-command.patch (text/x-patch, attachment)]

[0005-Support-receiving-from-DCC-SSEND-in-erc-dcc.patch (text/x-patch, attachment)]

Message #94 received at 54458 <at> debbugs.gnu.org (full text, mbox):

From: Fernando de Morais <fernandodemorais.jf <at> gmail.com>
To: "J.P." <jp <at> neverwas.me>
Cc: Mattias Engdegård <mattiase <at> acm.org>,
 Eli Zaretskii <eliz <at> gnu.org>, emacs-erc <at> gnu.org, bandali <at> gnu.org,
 54458 <at> debbugs.gnu.org
Subject: Re: bug#54458: 27.2; erc-dcc-get: Re-entering top level after C
 stack overflow
Date: Sat, 07 May 2022 22:16:40 -0300

Hello J.P.,

"J.P." <jp <at> neverwas.me> writes:

> And without more insight into what's going on precisely with your
> inputs, I don't think there's a whole lot we can do beyond speculate.
> So, in the end, I guess I'm just asking you to suffer the status quo on
> this one.

No problem! Your patches solved the main problem I was facing, so the
small inconvenience of an unresponsive Emacs for very short periods of
time doesn't affect my experience that much.

> If you're able to try these, great. If not, no worries.

Although with these new suggested changes, which I applied, I was able
to perform several large file transfers (about twenty in total, divided
in five blocks of four simultaneous transfers) without experiencing any
loss of control from Emacs!

In all transfers I used the `-t' and `-s' flags (although I think the
sender doesn't support the SSEND detection).

> I'll leave them for a bit anyhow to focus on our main
> initiatives. Thanks for bearing with me all these weeks (and with ERC
> all these years)!

I wish all the luck for these main initiatives of yours and I would like
to take this opportunity to thank you for your patience and your
commitment to solve the problem, including the inconveniences that arose
with the first solution proposed.

I hope the ERC team implements your suggested changes.

Thanks!

-- 
Regards,
Fernando de Morais.

Message #97 received at 54458 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Fernando de Morais <fernandodemorais.jf <at> gmail.com>
Cc: Mattias Engdegård <mattiase <at> acm.org>,
 Eli Zaretskii <eliz <at> gnu.org>, emacs-erc <at> gnu.org, bandali <at> gnu.org,
 54458 <at> debbugs.gnu.org
Subject: Re: bug#54458: 27.2; erc-dcc-get: Re-entering top level after C
 stack overflow
Date: Wed, 11 May 2022 07:29:00 -0700

Fernando de Morais <fernandodemorais.jf <at> gmail.com> writes:

> Although with these new suggested changes, which I applied, I was able
> to perform several large file transfers (about twenty in total, divided
> in five blocks of four simultaneous transfers) without experiencing any
> loss of control from Emacs!

Fifth time's a charm!

> I wish all the luck for these main initiatives of yours and I would
> like to take this opportunity to thank you for your patience and your
> commitment to solve the problem, including the inconveniences that
> arose with the first solution proposed.

Appreciate the kind words, truly.

> I hope the ERC team implements your suggested changes.

As do I!

On that note, unless anyone objects, I will install the most recent
iteration (or similar) on or around May 20, which is roughly nine days
from now. The ERC version will remain unchanged at 5.4.1. Thanks.

Message #102 received at 54458-done <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: 54458-done <at> debbugs.gnu.org
Cc: emacs-erc <at> gnu.org
Subject: Re: bug#54458: 27.2; erc-dcc-get: Re-entering top level after C
 stack overflow
Date: Sun, 22 May 2022 18:22:55 -0700

"J.P." <jp <at> neverwas.me> writes:

> On that note, unless anyone objects, I will install the most recent
> iteration (or similar) on or around May 20, which is roughly nine days
> from now. The ERC version will remain unchanged at 5.4.1. Thanks.

Done. Thanks. Closing.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.