GNU bug report logs - #21380
25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: rudalics <at> gmx.at, monnier <at> IRO.UMontreal.CA, pipcet <at> gmail.com,
 21380 <at> debbugs.gnu.org
Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer
 from window-configuration-change-hook
Date: Fri, 29 Apr 2022 16:40:26 +0300

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: Stefan Monnier <monnier <at> IRO.UMontreal.CA>,  rudalics <at> gmx.at,
>   pipcet <at> gmail.com,  21380 <at> debbugs.gnu.org
> Date: Fri, 29 Apr 2022 20:52:02 +0800
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > I believe the currently preferred solution is to block input and
> > atimers while copying the timer lists to local copies.  Are you okay
> > with that?
> 
> Please forgive my ignorance, but why do atimers have to be blocked in
> situations where Lisp code isn't supposed to run?  I don't think we ever
> run Lisp inside an atimer, and AFAICT atimers are active in most of the
> code where Lisp shouldn't run.

First, I see no guarantee that atimers cannot run Lisp, ever.  And
second, even if they don't run Lisp, they could run code which
directly or indirectly modifies Vtimer_list, and we cannot allow that
in this case.

IOW, the problem is not that Lisp isn't supposed to run in this
situation, the problem is that we examine and modify Vtimer_list, so
we cannot allow any code that could potentially modify that behind our
backs while we are at that.

Previous Next

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