GNU bug report logs - #60220
29.0.60; macOS 13.1 crash shortly after starting Emacs

Previous Next

Package: emacs;

Reported by: Aaron Jensen <aaronjensen <at> gmail.com>

Date: Tue, 20 Dec 2022 15:12:01 UTC

Severity: normal

Found in version 29.0.60

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: gerd.moellmann <at> gmail.com, 60220 <at> debbugs.gnu.org, aaronjensen <at> gmail.com
Subject: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
Date: Fri, 30 Dec 2022 10:37:05 +0200
> Date: Thu, 29 Dec 2022 17:16:18 -0800
> Cc: Eli Zaretskii <eliz <at> gnu.org>, gerd.moellmann <at> gmail.com,
>  60220 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> 
> On 12/29/22 16:03, Aaron Jensen wrote:
> > Would it make sense to use block_atimers while loading native lisp? If
> 
> Might, but it might make more sense not to be dynamically loading code 
> during an idle timer.

This is a limitation we don't want, as it is too severe.  How can we
prevent loading when idle timers can run any Lisp, and an arbitrary
Lisp program can always call some autoloaded function?

And I don't understand why we'd want to have such a restriction, since
idle timers run from the main loop, thus in safe context.  It would be
a gratuitous restriction that will only draw (justified) complaints.

Can you explain why you think loading shared libraries from an Emacs
idle timer could be dangerous?  I don't think I understand that.




This bug report was last modified 2 years and 158 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.