Hello J.P.,

First of all, thanks for checking my bug report.

"J.P." <jp@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.