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

Previous Next

Package: emacs;

Reported by: Pip Cet <pipcet <at> gmail.com>

Date: Sun, 30 Aug 2015 12:52:02 UTC

Severity: normal

Found in version 25.0.50

Fixed in version 29.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


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

From: Pip Cet <pipcet <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 21380 <at> debbugs.gnu.org
Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer
 from window-configuration-change-hook
Date: Sun, 30 Aug 2015 20:56:33 +0000
[Message part 1 (text/plain, inline)]
On Sun, Aug 30, 2015 at 7:44 PM, Eli Zaretskii <eliz <at> 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.
[Message part 2 (text/html, inline)]

This bug report was last modified 3 years and 79 days ago.

Previous Next


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