bug#70914: 29.3; Crashes often on Windows

[Eli Zaretskii <eliz@gnu.org>]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Simen Endsjø <simendsjo@gmail.com>, ssbssa@yahoo.de,
>  corwin@bru.st,
>  70914@debbugs.gnu.org
> Date: Thu, 23 May 2024 10:30:11 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >>     Lisp Backtrace:
> >>     "file-exists-p" (0xbf6f20)
> >>     "or" (0xbf7130)
> >>     "if" (0xbf72e0)
> >>     0xa9e7f40 Lisp type 3
> >>     "org-activate-links--overlays" (0x4badb48)
> >>     "org-activate-links" (0x4badac0)
> >>     "font-lock-fontify-keywords-region" (0x4bada20)
> >
> > This seems to tell that font-lock calls org-activate-links, which
> > calls org-activate-links--overlays, which somehow ends up calling
> > file-exists-p with the "file name" that is "//".  I don't see how this
> > can happen, but my guess is that this is somehow related to the Org
> > file being visited and displayed, so the contents of that file might
> > hold a part of the solution for this riddle.  Do you have a lot of
> > links in that Org file?  If not, could you perhaps show them?
> >
> > Ihor, can you help?  How can org-activate-links--overlays end up
> > calling file-exists-p, and what should we look for in the Org file to
> > understand why it calls file-exists-p with "//"?  I'm guessing this
> > might be related to the htmlize-link or help-echo properties of Org
> > links?
> 
> This is not something Org does directly.
> We allow custom link fontification function set via :activate-func link
> parameter. One of the common ways to use this :activate-func is to
> highlight files that do not exist with different face.
> 
> Since the report appears to be for Doom Emacs, the likely code
> responsible for calling `file-exists-p' is
> https://github.com/doomemacs/doomemacs/blob/master/modules/lang/org/config.el#L500

Could be.  But that function alone doesn't explain the behavior, since
it calls file-exists-p on the entire file name, and evaluating

  (file-exists-p "file://")

doesn't get me to the code in w32.c that misbehaved until recently
when presented with "//".

So something else is at work here.  And note that all of the
backtraces have this at the top:

    Lisp Backtrace:
    "file-exists-p" (0xbf6f20)
    "or" (0xbf7130)
    "if" (0xbf72e0)
    0xa9e7f40 Lisp type 3
    "org-activate-links--overlays" (0x4badb48)
    "org-activate-links" (0x4badac0)
    "font-lock-fontify-keywords-region" (0x4bada20)

So org-activate-links is somehow involved in this.