GNU bug report logs -
#70914
29.3; Crashes often on Windows
Previous Next
Reported by: Simen Endsjø <simendsjo <at> gmail.com>
Date: Mon, 13 May 2024 08:49:02 UTC
Severity: normal
Found in version 29.3
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
I managed to narrow it down further. Org incorrectly finds file:// links. I have
some string concatenation in an emacs-lisp source block line `(concat "file://"
"foo")`, and this breaks org.
I used the following function to extract all links, added them to a separate
org file and went through them.
(defun emacs-bug-70914/print-org-links ()
(interactive)
(save-excursion
(beginning-of-buffer)
(while (re-search-forward org-link-any-re nil t)
(message "link: %s" (match-string 0)))))
The following crashes
#+begin_src emacs-lisp
"file://"
#+end_src
Other combinations also crashes
#+begin_src emacs-lisp
(message "src=\"file://")
#+end_src
#+begin_src emacs-lisp
"src=\"file://"
#+end_src
On Thu, May 23, 2024 at 7:19 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: Simen Endsjø <simendsjo <at> gmail.com>
> > Date: Wed, 22 May 2024 22:28:04 +0200
> > Cc: ssbssa <at> yahoo.de, corwin <at> bru.st, 70914 <at> debbugs.gnu.org
> >
> > Here's some output when printing filenames in get_volume_info. I've tried
> > searching around and reading code, but I haven't found out where
> > "d:/profiles/%s" or "//" comes from.
>
> I don't think "d:/profiles/%s" is the problem, but just in case: what
> is that directory? Is it some place you keep your init or config
> files? Does any Emacs variable or environment variable point to
> "d:/profiles"?
>
> > name="d:/.emacs.d/.local/straight/build-29.3/org-fancy-priorities/org-fancy-priorities.elc"
> > get_volume_info: name="c:/Users/simend/.ssh/id_rsa"
> > get_volume_info: name="d:/profiles/%s"
> > get_volume_info: name="//"
>
> It sounds like the "//" file name comes from here:
>
> > 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 bug report was last modified 1 year and 54 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.