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

Previous Next

Full log

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

From: Aaron Jensen <aaronjensen <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, Paul Eggert <eggert <at> cs.ucla.edu>,
 60220 <at> debbugs.gnu.org
Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
Date: Fri, 30 Dec 2022 08:36:25 -0500

On Fri, Dec 30, 2022 at 3:37 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > 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.

I've already disproven this. I can reproduce a crash with just an
after-init hook loading several features.

Aaron

Previous Next

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