From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.bugs Subject: 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-ID: References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> <83h9ng1ryx.fsf@gnu.org> <83a8t71qct.fsf@gnu.org> <83fv2ychbg.fsf@gnu.org> <838u8qcenv.fsf@gnu.org> <55E69F07.9060006@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11403558f1194a051f3e630e X-Trace: ger.gmane.org 1441727787 19756 80.91.229.3 (8 Sep 2015 15:56:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 8 Sep 2015 15:56:27 +0000 (UTC) Cc: 21380@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Sep 08 17:56:11 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZZLFi-0000Gl-Kc for geb-bug-gnu-emacs@m.gmane.org; Tue, 08 Sep 2015 17:56:10 +0200 Original-Received: from localhost ([::1]:35367 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZLFi-0000Rt-Ff for geb-bug-gnu-emacs@m.gmane.org; Tue, 08 Sep 2015 11:56:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59304) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZLFd-0000RX-DZ for bug-gnu-emacs@gnu.org; Tue, 08 Sep 2015 11:56:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZZLFa-0005WA-7j for bug-gnu-emacs@gnu.org; Tue, 08 Sep 2015 11:56:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:60613) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZLFa-0005W5-4e for bug-gnu-emacs@gnu.org; Tue, 08 Sep 2015 11:56:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZZLFZ-0002xL-Td for bug-gnu-emacs@gnu.org; Tue, 08 Sep 2015 11:56:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 08 Sep 2015 15:56:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21380 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21380-submit@debbugs.gnu.org id=B21380.144172771311297 (code B ref 21380); Tue, 08 Sep 2015 15:56:01 +0000 Original-Received: (at 21380) by debbugs.gnu.org; 8 Sep 2015 15:55:13 +0000 Original-Received: from localhost ([127.0.0.1]:52823 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZLEm-0002w8-F1 for submit@debbugs.gnu.org; Tue, 08 Sep 2015 11:55:13 -0400 Original-Received: from mail-io0-f169.google.com ([209.85.223.169]:36817) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZLEj-0002vt-G0 for 21380@debbugs.gnu.org; Tue, 08 Sep 2015 11:55:10 -0400 Original-Received: by ioii196 with SMTP id i196so123289815ioi.3 for <21380@debbugs.gnu.org>; Tue, 08 Sep 2015 08:55:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2ZnJ/LlMdgrRJnbXqxJdbSVCKR1qcig0Cn82NJZs1Zs=; b=ciomQGBLze+439H1gqBN5rOtJF1vxwJo1c86NQz/UNKgWy2wEb/OTD+3hsxScyDACF H2co7sqZ7gw3KVbXFw9lCiB6UZTVb+mC1k/qldFJDyELAWURfj5XOQb8YqXqRkv4MaFX obbgZFPaoNlxT3gRoyL0YOiTbvqKnH4FbIFNMFC6ZAJ66juHEOoWRHhWYIvclggXxsSH uC0I2EX5xPdM86Prd9ZxCOOPct2bchXUDK6EyU26F7bteklYHFYDczrgsefgWE+YY5s8 IEorfm3Stah5Y8qkvChiy0k5nwaQgRRN+KidyhlQ8o38cXIRZcCkSZ8mzKuJ91dVFd+P m4OA== X-Received: by 10.107.163.19 with SMTP id m19mr45095740ioe.65.1441727708729; Tue, 08 Sep 2015 08:55:08 -0700 (PDT) Original-Received: by 10.79.78.66 with HTTP; Tue, 8 Sep 2015 08:55:08 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:106249 Archived-At: --001a11403558f1194a051f3e630e Content-Type: text/plain; charset=UTF-8 On Sun, Sep 6, 2015 at 10:22 PM, Stefan Monnier 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). --001a11403558f1194a051f3e630e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Sep 6, 2015 at 10:22 PM, Stefan Monnier <monnier@iro.umontrea= l.ca> wrote:
> (El= i correctly objected to my initial idea that the rule should be
> "never",

Hmm... "never" does sound enticing, tho clearly debug-on-q= uit
challenges the idea.

I think I've narrow= ed down the situations in which we actually run elisp from QUIT:
1. delete_frame (it has a Qnoelisp argument, but runs elisp an= yway)
2. decoding C strings from X events
3. so= me 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

<= /div>
3, 5, 6, and probably 1 can be fixed by running those handlers fr= om 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 argume= nt to some of the face handling code and delaying mouseover updates in thos= e (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 us= ers).

(This list is valid for my build configu= ration 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 me= ans "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.=C2=A0 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 s= ome others we'd have to check by hand.
=C2=A0
> that QUIT shouldn't call hooks, but should be able to call isolate= d
> functions implemented in Lisp, such as those used for relative font si= zing).

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 im= portant enough that we should make them work, even if our policy for arbitr= ary advice is "don't do that".

The only pro= blem 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). nre= verse and delq seem safe. nconc and anything using equal, not so much. (I&#= 39;m not sure why assoc_no_quit is called that, since it calls Fequal which= QUITs).
--001a11403558f1194a051f3e630e--