> 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 <
eliz@gnu.org> wrote:
>
> > Date: Fri, 24 May 2024 12:07:23 +0200
> >
> > 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++;
> }