Eli Zaretskii writes: >> From: Thierry Volpiatto >> Date: Tue, 07 Jun 2022 15:16:36 +0000 >> >> >> I can't reproduce from emacs -Q using M-x find-file, but the bug happens >> with Helm when using M-x helm-find-files /sudo:: >> Emacs freeze and then in gdb: >> >> Thread 1 "emacs" received signal SIGSEGV, Segmentation fault. >> 0x0000555555837be7 in doprnt.part () >> >> In all previous emacs this worked normally, working fine here in >> emacs-28.1. >> This is a followup of bug #55555. >> >> I can send more infos from gdb if you give me instructions, I tried bt >> but the output is huge. > > The first step is to figure out what was the immediate reason for the > segfault, and in which source line it happened. > > Your build is heavily optimized, so I suggest to rebuild with the > following additional compiler options: > > -gdwarf-4 -g3 I have now rebuilded with: ./configure CFLAGS='-08 -gdwarf-4 -g3' --with-native-compilation First try with /sudo:: I couldn't reproduce, then I waited the native-compilation fully finish and could reproduce. When fixing other warnings this morning I saw this warning in *Warnings* buffer: /usr/local/share/emacs/site-lisp/helm/helm-files.el: Error: Wrong type argument sequencep But couldn't figure out what is this error, I have no error or warnings when compiling and everything work fine in emacs-28, don't know if this could be related to this crash. > Then run Emacs under GDB, and when it crashes, type > > (gdb) thread 1 > (gdb) bt -full 5 > > and post the results. [...] [Detaching after vfork from child process 229481] Thread 1 "emacs" received signal SIGSEGV, Segmentation fault. 0x0000555555837be7 in doprnt (buffer=0x7fffff6702c0 "", bufsize=4000, format=0x5555558af29a "Bytecode stack overflow", ap=0x7fffff670250, format_end=) at doprnt.c:186 186 doprnt (char *buffer, ptrdiff_t bufsize, const char *format, (gdb) thread 1 [Switching to thread 1 (Thread 0x7ffff07ce3c0 (LWP 226687))] #0 0x0000555555837be7 in doprnt (buffer=0x7fffff6702c0 "", bufsize=4000, format=0x5555558af29a "Bytecode stack overflow", ap=0x7fffff670250, format_end=) at doprnt.c:186 186 doprnt (char *buffer, ptrdiff_t bufsize, const char *format, (gdb) bt -full 5 #0 0x0000555555837be7 in doprnt (buffer=0x7fffff6702c0 "", bufsize=4000, format=0x5555558af29a "Bytecode stack overflow", ap=0x7fffff670250, format_end=) at doprnt.c:186 fmt = bufptr = tembuf = '\000' size_allocated = sprintf_buffer = big_buffer = quoting_style = #1 0x0000555555838a57 in doprnt (ap=0x7fffff670250, format_end=0x0, format=0x5555558af29a "Bytecode stack overflow", bufsize=, buffer=) at doprnt.c:590 modifier_len = "\000\001\001\001\001" nbytes = ap_copy = {{gp_offset = 8, fp_offset = 48, overflow_arg_area = 0x7fffff671380, reg_save_area = 0x7fffff6712c0}} #2 evxprintf (buf=buf@entry=0x7fffff6702b8, bufsize=bufsize@entry=0x7fffff6702b0, nonheapbuf=nonheapbuf@entry=0x7fffff6702c0 "", bufsize_max=bufsize_max@entry=2305843009213693952, format=0x5555558af29a "Bytecode stack overflow", ap=ap@entry=0x7fffff6712a0) at doprnt.c:590 nbytes = ap_copy = {{gp_offset = 8, fp_offset = 48, overflow_arg_area = 0x7fffff671380, reg_save_area = 0x7fffff6712c0}} #3 0x00005555557aa5f3 in vformat_string (m=, ap=ap@entry=0x7fffff6712a0) at eval.c:2029 buf = '\000' ... size = 4000 buffer = 0x7fffff6702c0 "" used = string = #4 0x00005555555aac6f in verror (m=, ap=ap@entry=0x7fffff6712a0) at eval.c:2041 (More stack frames follow...) -- Thierry