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

[Pip Cet]

On Sun, Aug 30, 2015 at 7:44 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> I'm not sure I understand. This issue is happening while the temporary copy is
> being created, not afterwards, IIUC.

Then all we have to do is block QUIT during that copy, no?

Yes for this particular segfault.

No* for similar segfaults that I think pose equally severe problems: if any other function calls concat/copy-sequence on data that is modified by window-configuration-change-hook, it should* still be possible to produce the segfault. So it wouldn't even be safe for window-configuration-change-hook to add a timer to the timer list, because the outer frame might be in the middle of creating a copy of the timer list for some Lisp code that hasn't blocked input. (As in my example below)

I really don't think QUIT should run any Lisp hooks, to be honest. From the point of view of the Lisp user (and the not-totally-careful C user, as in this case), that might make them happen at any time, and all kinds of race conditions would occur instead. Maybe this is a matter for emacs-devel?

If I'm wrong and QUIT should be able to run Lisp hooks, concat needs to be fixed not to rely on its argument's size being unchanged after the make_sequence call.

*-I have been able to verify this segfault by interrupting the program at just the right time and resizing its X window then:
 - gdb --args emacs -Q
 - evaluate the following code:

(run-with-timer 0 1 #'ignore) ;; so the timer list isn't empty
(add-hook 'window-configuration-change-hook (lambda () (run-with-timer 0 nil #'ignore)))

(while t
  (copy-sequence timer-list)
  (accept-process-output nil 0)
  )

 - interrupt and set a breakpoint with "b Fmake_sequence if !input_blocked_p()".
 - wait for breakpoint to be hit, verify that concat's args[0] is equal to Vtimer_list.

 - resize the X window

 - continue in gdb

 - segfault

As far as I can tell, that should be reproducible. Also as far as I can tell, it's merely a matter of luck that an X resize doesn't happen at the point where I interrupted the program to artificially trigger the segfault. However, I admit that it is a separate issue, less likely to occur in practice, and I'll open another bug for it if that's the way you prefer things.