bug#70914: 29.3; Crashes often on Windows

["Simen Endsjø" <simendsjo@gmail.com>]

> 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:
>
> > From: Simen Endsjø <simendsjo@gmail.com>
> > 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++;
>         }