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: Wed, 2 Sep 2015 22:08:00 +0000 Message-ID: References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> <83h9ng1ryx.fsf@gnu.org> <83a8t71qct.fsf@gnu.org> <837foaceid.fsf@gnu.org> <83vbbuawgy.fsf@gnu.org> <83a8t4c10v.fsf@gnu.org> <83y4goab2r.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1144ac345d6b6a051ecae684 X-Trace: ger.gmane.org 1441231798 23534 80.91.229.3 (2 Sep 2015 22:09:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 2 Sep 2015 22:09:58 +0000 (UTC) Cc: 21380@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Sep 03 00:09:43 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 1ZXGDO-0000d9-KY for geb-bug-gnu-emacs@m.gmane.org; Thu, 03 Sep 2015 00:09:10 +0200 Original-Received: from localhost ([::1]:41889 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXGDO-0000wc-7i for geb-bug-gnu-emacs@m.gmane.org; Wed, 02 Sep 2015 18:09:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33409) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXGDJ-0000wN-Bb for bug-gnu-emacs@gnu.org; Wed, 02 Sep 2015 18:09:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZXGDG-0002Ua-46 for bug-gnu-emacs@gnu.org; Wed, 02 Sep 2015 18:09:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:54813) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXGDG-0002UU-1f for bug-gnu-emacs@gnu.org; Wed, 02 Sep 2015 18:09:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZXGDF-0000Zv-KB for bug-gnu-emacs@gnu.org; Wed, 02 Sep 2015 18:09:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Sep 2015 22:09: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.14412316842152 (code B ref 21380); Wed, 02 Sep 2015 22:09:01 +0000 Original-Received: (at 21380) by debbugs.gnu.org; 2 Sep 2015 22:08:04 +0000 Original-Received: from localhost ([127.0.0.1]:47023 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXGCK-0000Ye-4q for submit@debbugs.gnu.org; Wed, 02 Sep 2015 18:08:04 -0400 Original-Received: from mail-io0-f181.google.com ([209.85.223.181]:34654) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXGCH-0000YD-Ci for 21380@debbugs.gnu.org; Wed, 02 Sep 2015 18:08:02 -0400 Original-Received: by iofb144 with SMTP id b144so37431351iof.1 for <21380@debbugs.gnu.org>; Wed, 02 Sep 2015 15:08:00 -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=fVnfSM+WAEfw7nqeO2wI6haIHWmmzYmC+mkWZRmYmYw=; b=Ysdvh7NkOwDcJFn24EeTK2mbEV/mGmJDH+2tHfGpZmR938y+muSycWybWZ9ver3G1+ tCvG71bfnxDhFFMK3BU7b3RVAIOFoTPS7mXyX6c2SzoNhAECb7qo3eDqsAQ7hIGyQDt4 +0NSdROtDxPwlTaXkw+GRX9KhMaFK98OeEK5gi5ASLzagq+eEjO2prM9HK6AX/LbXSA1 Y8DYogUYSFVC7rGhfGqwvdveLkImKopOLN1duQvF/0LBWDlRwkruS758vl/aoBV/I1Dl /9dryzfypBYowFU43lezZmS9lrXeopXihxk2/R/rR2nkYv/YXTKvxxF/SmuUvo5Uvdd8 daRQ== X-Received: by 10.107.47.97 with SMTP id j94mr38022672ioo.136.1441231680660; Wed, 02 Sep 2015 15:08:00 -0700 (PDT) Original-Received: by 10.79.78.66 with HTTP; Wed, 2 Sep 2015 15:08:00 -0700 (PDT) In-Reply-To: <83y4goab2r.fsf@gnu.org> 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:106098 Archived-At: --001a1144ac345d6b6a051ecae684 Content-Type: text/plain; charset=UTF-8 On Wed, Sep 2, 2015 at 7:13 PM, Eli Zaretskii wrote: > > Date: Wed, 2 Sep 2015 16:09:53 +0000 > > From: Pip Cet > > Cc: 21380@debbugs.gnu.org > > > > > I think it's safe to assume that Lisp timers are only checked if > atimers > > are > > > enabled. > > > > Those are two completely separate and independent features, so no, > > it's not safe to make that assumption. Not sure why you need to > > assume that, though. > > > > So we can call turn_on_atimers (true) without potentially enabling > atimers in a > > critical section. > > My confusion just grew a notch: one of these "atimers" is actually > Lisp timers, right? No, I don't think so. If not, I'm afraid I don't see what you mean. > See below, those were two attempts of mine to describe the same thing. > My assumption was that the reason we have both Lisp timers and atimers is > that > > atimers run strictly more often than Lisp timers. > > They can be more accurate, but I see no reason why they should run > more often. > Sorry for being unclear. I should have said something like "have strictly more opportunities to run than Lisp timers". > > > If it isn't, I think the best way forward is to write > > > block_input_and_atimers () and lock atimers with a counter just > like > > input is. > > > > Not sure I follow you. Are you saying that just calling block_input > > followed by turn_on_atimers is somehow not enough to prevent some > Lisp > > from changing Vtimer_list under our feet? > > > > > > I'm not saying that, no, but if another function disables atimers, then > runs > > Lisp timers, then does something critical that needs atimers to be > disabled, it > > might break. > > We didn't need to disable atimers until now, except when manipulating > the atimers themselves. > > The function we are discussing, which copies > Lisp timers, is the first one in need of this. So I don't yet see the > need for a counter, but I don't object to one, either. > That's how I feel about disabling atimers at all. I think it's only for future atimer code that does something dangerous. Maybe I'm missing something obvious, but there isn't currently any call path from the atimers to Lisp code. --001a1144ac345d6b6a051ecae684 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Sep 2, 2015 at 7:13 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> Date: Wed, 2 Sep 2015 16:09:53 +0000<= br> > From: Pip Cet <pipcet@gmail.com>
> Cc: 21380@d= ebbugs.gnu.org
>
>=C2=A0 =C2=A0 =C2=A0> I think it's safe to assume t= hat Lisp timers are only checked if atimers
>=C2=A0 =C2=A0 =C2=A0are
>=C2=A0 =C2=A0 =C2=A0> enabled.
>
>=C2=A0 =C2=A0 =C2=A0Those are two completely separate and independent f= eatures, so no,
>=C2=A0 =C2=A0 =C2=A0it's not safe to make that assumption. Not sure= why you need to
>=C2=A0 =C2=A0 =C2=A0assume that, though.
>
> So we can call turn_on_atimers (true) without potentially enabling ati= mers in a
> critical section.

My confusion just grew a notch: one of these "atimers" is = actually
Lisp timers, right?

No, I don't think s= o.

If not, I'm afraid I don= 't see what you mean.

See below, th= ose were two attempts of mine to describe the same thing.
> My assumption was that the reason we have both Lisp timers and atimers= is that
> atimers run strictly more often than Lisp timers.

They can be more accurate, but I see no reason why they should run more often.

Sorry for bein= g unclear. I should have said something like "have strictly more oppor= tunities to run than Lisp timers".
=C2=A0
>=C2=A0 =C2=A0 =C2=A0> If it isn't, I think the best way forward = is to write
>=C2=A0 =C2=A0 =C2=A0> block_input_and_atimers () and lock atimers wi= th a counter just like
>=C2=A0 =C2=A0 =C2=A0input is.
>
>=C2=A0 =C2=A0 =C2=A0Not sure I follow you. Are you saying that just cal= ling block_input
>=C2=A0 =C2=A0 =C2=A0followed by turn_on_atimers is somehow not enough t= o prevent some Lisp
>=C2=A0 =C2=A0 =C2=A0from changing Vtimer_list under our feet?
>
>
> I'm not saying that, no, but if another function disables atimers,= then runs
> Lisp timers, then does something critical that needs atimers to be dis= abled, it
> might break.

We didn't need to disable atimers until now, except when manipul= ating
the atimers themselves.
=C2=A0
The function we are discussing, which copies
Lisp timers, is the first one in need of this.=C2=A0 So I don't yet see= the
need for a counter, but I don't object to one, either.
=

That's how I feel about disabling atimers at all. I= think it's only for future atimer code that does something dangerous. = Maybe I'm missing something obvious, but there isn't currently any = call path from the atimers to Lisp code.
--001a1144ac345d6b6a051ecae684--