Hi Fernando, Fernando de Morais 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.