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

Previous Next

Full log

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

From: Pip Cet <pipcet <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>,
 21380 <at> debbugs.gnu.org
Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer
 from window-configuration-change-hook
Date: Tue, 8 Sep 2015 15:55:08 +0000

[Message part 1 (text/plain, inline)]

On Sun, Sep 6, 2015 at 10:22 PM, Stefan Monnier <monnier <at> iro.umontreal.ca>
wrote:

> > (Eli correctly objected to my initial idea that the rule should be
> > "never",
>
> Hmm... "never" does sound enticing, tho clearly debug-on-quit
> challenges the idea.
>

I think I've narrowed down the situations in which we actually run elisp
from QUIT:

1. delete_frame (it has a Qnoelisp argument, but runs elisp anyway)
2. decoding C strings from X events
3. some of the new window resizing code (resize_frame_windows,
frame_windows_min_size, sanitize_window_sizes)
4. mouse highlighting
5. x_kill_gs_process runs a lot of stuff, probably including elisp
6. the GTK toolbar/menubar callbacks still appear to be running
window-configuration-change-hook, unless I'm missing something

3, 5, 6, and probably 1 can be fixed by running those handlers from the
command loop. (2) could be fixed by keeping the untranslated string around
until we actually need it decoded, but that's more difficult (in
particular, we need to recognize the quit character even when other input
events are not handled). (4) would probably involve adding a noelisp
argument to some of the face handling code and delaying mouseover updates
in those (rare, hopefully) cases in which the face isn't actually loaded
yet. (The easy way to solve (4) would be not to do mouseover faces until we
get back to the command loop, but I fear that would be unacceptable for
most users).

(This list is valid for my build configuration only, I've not even started
to look at the windows/OS X code).

> but I still think it should be "much less often than we currently do".
>
> OTOH, as soon as it's not "never", then it tends to means "be prepared:
> this can run arbitrary Elisp code".
>
> So maybe the issue is not just "when" but also "what": we could limit
> the kind of Elisp code that's run by QUIT.  This is a lot more
> difficult, tho.
>

Well, we could limit some of the cases to side-effect-free functions that
don't use global variables, but I think that's too limiting. We can go the
other way, however, and declare such pure functions safe, in addition to
some others we'd have to check by hand.

>
> > that QUIT shouldn't call hooks, but should be able to call isolated
> > functions implemented in Lisp, such as those used for relative font
> sizing).
>
> And then someone wants to add an advice on those functions
> (e.g. debug-on-entry, trace-function, you name it), and suddenly your
> carefully coded function ends up doing all kinds of other things.
>

I think debug-on-entry and trace-function are important enough that we
should make them work, even if our policy for arbitrary advice is "don't do
that".

The only problem is data shared between ordinary Lisp and QUIT-run Lisp,
and even then there are many safe cases (for example, anything that doesn't
return is safe, and so is updating a list by consing together a new copy
first). nreverse and delq seem safe. nconc and anything using equal, not so
much. (I'm not sure why assoc_no_quit is called that, since it calls Fequal
which QUITs).

[Message part 2 (text/html, inline)]

Previous Next

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