bug#70914: 29.3; Crashes often on Windows

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

> 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.

I reduced it a bit earlier and tried again now. If I remove org-fancy-priorities
(and org-superstar) the problem goes away. So it might be related. The
org-superstar package states there is some "intricate timing issues". I reported
an issue pointing to this thread Thursday, but haven't heard anything yet, ref
https://github.com/integral-dw/org-superstar-mode/issues/55.

I tried adding only org-fancy-priorities and org-superstar to a clean emacs, but
couldn't reproduce the issue, so more stars have to align to trigger this.

On Wed, May 22, 2024 at 8:19 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > 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).