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

[Pip Cet]

On Sun, Sep 6, 2015 at 10:22 PM, Stefan Monnier <monnier@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).