bug#70914: 29.3; Crashes often on Windows

[Eli Zaretskii]

> From: Simen Endsjø <simendsjo@gmail.com>
> Date: Wed, 22 May 2024 18:54:06 +0200
> Cc: ssbssa@yahoo.de, corwin@bru.st, 70914@debbugs.gnu.org
> 
> > You can now remove the added condition and the call to emacs_abort
> > from the code.  Please run for a while and see if there are any other
> > crashes like that one, which yield a zero code address.
> 
> Yes, I'll use this version for a while and see if things get better.

Thanks.

> > Thanks.  Too much is involved here, but my money is on consult: I see
> > in its code several places where it matches file names in a way that
> > can only work on Posix systems (i.e., assuming absolute file names
> > begin with a slash, not with a drive letter).  Since
> > consult-recent-file is in the Lisp backtrace, it's a definite
> > possibility.
> 
> I can reproduce it calling just find-file too:

Yes, I know.  It reproduces the problem even in "emacs -Q".  I used
that to test the fix.  But if the user manually types such an invalid
file name, it is on him/her.  What I wanted to try to find is whether
some of our Lisp packages _generates_ such a "file name", which would
be a bug we'd need to fix.

But note how many unknowns are involved in your find-file example:

   doom--shut-up-autosave-a
   so-long--set-auto-mode
   +evil--persist-state-a
   evil-save-state
   org-mode
   org-fancy-priorities-mode
   org-activate-links
   org-activate-links--overlays

If you can somehow spot what causes this "//" name to appear in this
case, do tell.  E.g., if it's the fault of Org, then we'd want to fix
that.

It is important to understand that "//" is an invalid file name on
Windows, as far as Emacs is concerned, and using it will basically
produce results which are not useful.  E.g., try

  M-: (file-attributes "//") RET

(in the fixed Emacs, of course, and after removing the call to
emacs_abort in parse_root).