> Double checked, and no, looks like I've been accidentally running without the > patch (at least it's unpatched in the working tree)! I'll try running the > emacs-29 branch instead of emacs-29.3 with the patch manually applied. > > Let's see if this fixes the issue ;) I keep getting these errors even though I'm running with the "//" patch. Common for the crashes (when attaching gdb to the crashing process) is the following: #6 0x00007ffef66f49ff in ntdll!.chkstk () from C:\WINDOWS\SYSTEM32\ntdll.dll #7 0x00007ffef666e466 in ntdll!RtlFindCharInUnicodeString () from C:\WINDOWS\SYSTEM32\ntdll.dll I've been running without org-superstar and org-fancy-priorities. This time I got the error when calling `dired-sort-toggle-or-edit`. It's not reproducible in that folder after restarting though. Thread 1 (Thread 18588.0x5fd4): #0 0x00007ffef3ecd313 in KERNELBASE!DebugBreak () from C:\WINDOWS\System32\KernelBase.dll #1 0x00007ff78c040f28 in emacs_abort () #2 0x00007ff78bf0a389 in terminate_due_to_signal () #3 0x00007ff78bf2b249 in deliver_fatal_thread_signal () #4 0x00007ff78c0a6672 in _gnu_exception_handler (exception_data=0x377f9fdc00) at C:/M/B/src/mingw-w64/mingw-w64-crt/crt/crt_handler.c:213 #5 0x00007ffef4b6b248 in msvcrt!__C_specific_handler () from C:\WINDOWS\System32\msvcrt.dll #6 0x00007ffef66f49ff in ntdll!.chkstk () from C:\WINDOWS\SYSTEM32\ntdll.dll #7 0x00007ffef666e466 in ntdll!RtlFindCharInUnicodeString () from C:\WINDOWS\SYSTEM32\ntdll.dll #8 0x00007ffef66f39ee in ntdll!KiUserExceptionDispatcher () from C:\WINDOWS\SYSTEM32\ntdll.dll #9 0x00007ff78bfc3aa3 in print_object () #10 0x00007ff78bfc55d8 in Fprin1 () #11 0x00007ff78bfc5d33 in print_error_message () #12 0x00007ff78bf0c73d in Fcommand_error_default_function () #13 0x00007ffee4de1907 in F68656c702d636f6d6d616e642d6572726f722d636f6e66757361626c652d73756767657374696f6e73_help_command_error_confusable_suggestions_0 () from c:\programs\emacs\latest\lib\emacs\29.3\native-lisp\29.3-2771a4de\preloaded\help-59d8049f-5432716d.eln #14 0x00007ff78bfa0032 in Ffuncall () #15 0x00007ff78bf1346b in cmd_error_internal () #16 0x00007ff78bf135cf in cmd_error () #17 0x00007ff78bf9a66d in internal_condition_case () #18 0x00007ff78bf0ac32 in command_loop_2 () #19 0x00007ff78bf9a59b in internal_catch () #20 0x00007ff78bf0abcc in command_loop () #21 0x00007ff78bf12fe7 in recursive_edit_1 () #22 0x00007ff78bf133b0 in Frecursive_edit () #23 0x00007ff78c0b9b7d in main () On Fri, May 24, 2024, at 15:08, Simen Endsjø wrote: > > Are you running with the source of parse_root fixed, as in the current > > emacs-29 branch? If not, please rebuild Emacs with that patch before > > doing anything else. If you want, you install the patch locally, see > > the patch below. > > Double checked, and no, looks like I've been accidentally running without the > patch (at least it's unpatched in the working tree)! I'll try running the > emacs-29 branch instead of emacs-29.3 with the patch manually applied. > > Let's see if this fixes the issue ;) > > On Fri, May 24, 2024 at 12:47 PM Eli Zaretskii wrote: > > > > > From: Simen Endsjø > > > Date: Fri, 24 May 2024 12:07:23 +0200 > > > Cc: 70914@debbugs.gnu.org > > > > > > I still get these. Should I open a new issue for this as the bug > > > report has changed towards the path issue? > > > The path issue was only visible to me when debugging in gdb, so these > > > crashes (my original case) is still ongoing. > > > > Are you running with the source of parse_root fixed, as in the current > > emacs-29 branch? If not, please rebuild Emacs with that patch before > > doing anything else. If you want, you install the patch locally, see > > the patch below. > > > > > #0 0x00007ff9672dd313 in KERNELBASE!DebugBreak () from > > > C:\WINDOWS\System32\KernelBase.dll > > > #1 0x00007ff719eb0f28 in emacs_abort () > > > #2 0x00007ff719d7a389 in terminate_due_to_signal () > > > #3 0x00007ff719d9b249 in deliver_fatal_thread_signal () > > > #4 0x00007ff719f16672 in _gnu_exception_handler > > > (exception_data=0xb3a4dfb400) at > > > C:/M/B/src/mingw-w64/mingw-w64-crt/crt/crt_handler.c:213 > > > #5 0x00007ff968bbb248 in msvcrt!__C_specific_handler () from > > > C:\WINDOWS\System32\msvcrt.dll > > > #6 0x00007ff969b549ff in ntdll!.chkstk () from C:\WINDOWS\SYSTEM32\ntdll.dll > > > #7 0x00007ff969ace466 in ntdll!RtlFindCharInUnicodeString () from > > > C:\WINDOWS\SYSTEM32\ntdll.dll > > > #8 0x00007ff969b539ee in ntdll!KiUserExceptionDispatcher () from > > > C:\WINDOWS\SYSTEM32\ntdll.dll > > > #9 0x00007ff719dda17d in rpl_re_compile_pattern () > > > #10 0x00007ff719dcaf10 in compile_pattern () > > > #11 0x00007ff719dcb34d in looking_at_1 () > > > #12 0x00007ff719e10032 in Ffuncall () > > > #13 0x00007ff8e7591da7 in > > > F73702d736b69702d666f72776172642d746f2d73796d626f6c_sp_skip_forward_to_symbol_0 > > > () > > > from d:\.emacs.d\.local\cache\eln\29.3-2771a4de\smartparens-7ac9a6ec-f08b49fa.eln > > > > This seems like a different issue, so if rebuilding with the patch > > below doesn't help, please do open a new issue. And I will tell you > > already what we need to know for investigating: the arguments to > > looking_at_1. You should be able to show them like this: > > > > (gdb) frame 11 > > (gdb) p string > > (gdb) xstring > > > > The "frame 11" above assumes that the call to looking_at_1 is at > > call-stack frame #11, as in the above backtraces; if not, adjust the > > number accordingly. The command "xstring" is defined in src/.gdbinit, > > so if GDB says it doesn't know about it, do > > > > (gdb) source /path/to/emacs/src/.gdbinit > > > > and then repeat the above commands. > > > > Here's the patch which prevents crashes due to "//" file names: > > > > diff --git a/src/w32.c b/src/w32.c > > index d463962..a78d556 100644 > > --- a/src/w32.c > > +++ b/src/w32.c > > @@ -2572,7 +2572,7 @@ parse_root (const char * name, const char ** pPath) > > name += 2; > > do > > { > > - if (IS_DIRECTORY_SEP (*name) && --slashes == 0) > > + if (!*name || (IS_DIRECTORY_SEP (*name) && --slashes == 0)) > > break; > > name++; > > } >