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

Previous Next

Full log

Message #140 received at 60220 <at> debbugs.gnu.org (full text, mbox):

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

Previous Next

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