From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Barry OReilly Newsgroups: gmane.emacs.bugs Subject: bug#15561: periodic timer stops running Date: Fri, 28 Feb 2014 09:43:41 -0500 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c2a120ca04e404f37876d6 X-Trace: ger.gmane.org 1393598657 24407 80.91.229.3 (28 Feb 2014 14:44:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 28 Feb 2014 14:44:17 +0000 (UTC) To: eggert@cs.ucla.edu, pmlists@free.fr, 15561@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Feb 28 15:44:25 2014 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 1WJOfn-0000vt-5e for geb-bug-gnu-emacs@m.gmane.org; Fri, 28 Feb 2014 15:44:23 +0100 Original-Received: from localhost ([::1]:51619 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJOfm-0001fs-PM for geb-bug-gnu-emacs@m.gmane.org; Fri, 28 Feb 2014 09:44:22 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59268) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJOfd-0001fM-9K for bug-gnu-emacs@gnu.org; Fri, 28 Feb 2014 09:44:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WJOfT-0000qJ-4y for bug-gnu-emacs@gnu.org; Fri, 28 Feb 2014 09:44:13 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42648) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJOfS-0000oy-VK for bug-gnu-emacs@gnu.org; Fri, 28 Feb 2014 09:44:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WJOfS-0001SJ-0o for bug-gnu-emacs@gnu.org; Fri, 28 Feb 2014 09:44:02 -0500 X-Loop: help-debbugs@gnu.org In-Reply-To: Resent-From: Barry OReilly Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 28 Feb 2014 14:44:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15561 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 15561-submit@debbugs.gnu.org id=B15561.13935986305562 (code B ref 15561); Fri, 28 Feb 2014 14:44:01 +0000 Original-Received: (at 15561) by debbugs.gnu.org; 28 Feb 2014 14:43:50 +0000 Original-Received: from localhost ([127.0.0.1]:43830 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WJOfC-0001RU-Mo for submit@debbugs.gnu.org; Fri, 28 Feb 2014 09:43:47 -0500 Original-Received: from mail-oa0-f49.google.com ([209.85.219.49]:61285) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WJOf8-0001RA-H7 for 15561@debbugs.gnu.org; Fri, 28 Feb 2014 09:43:43 -0500 Original-Received: by mail-oa0-f49.google.com with SMTP id g12so2037510oah.36 for <15561@debbugs.gnu.org>; Fri, 28 Feb 2014 06:43:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=g+EXwgcQ6g92RbhBoZKs4R1h4ThzUEqKhBCDlAub/+k=; b=r2+0Ja/lcnuu7Mc1xB4ga/4tqyurAMm4ka6fPxDLPqSzYp7hVy9kmlP5Ix/ax6cp3B L/JwFmIeM+W5Psy5w/DEewEOZ5mno6VUi4XUp17IMrXSJQwLa132L9KnATbTagPK9McY A37Lrbfd/R+sJsBTn5PJr26P5cIve2/SuS6gV4HulV8Wb1a3abNSWdyeOCTpttodyrHw UWNOel/ihtGhrlZBl6YO9MqTyMWLvDhnZbuD9tZSU9A4vIZww4Hk/f8evD74Pgv5jgMs BdMBhkhSgsa15R42IInNjnOfIpWzkg+htZqm3kNjeNhlU8agz9yoYoAhjSU3nlyNh4WN 6wzw== X-Received: by 10.182.243.138 with SMTP id wy10mr956882obc.83.1393598621416; Fri, 28 Feb 2014 06:43:41 -0800 (PST) Original-Received: by 10.76.6.44 with HTTP; Fri, 28 Feb 2014 06:43:41 -0800 (PST) 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: 140.186.70.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:86394 Archived-At: --001a11c2a120ca04e404f37876d6 Content-Type: text/plain; charset=ISO-8859-1 > Are you talking about a SIGALRM received during the execution of > do_pending_atimers, between run_timer's call to set_alarm and > do_pending_atimers's call to unblock_atimers? If so, the SIGALRM > should be held by the operating system during that period, and Emacs > won't be informed of the SIGALRM until unblock_atimers does its > thing. Sorry, I don't see how this would cause a timer to stop. I see you're right, because SIGALRM isn't specified with SIG_IGN at any point. While verifying that, I found in sys_subshell: struct save_signal saved_handlers[5]; [...] #ifdef USABLE_SIGIO saved_handlers[3].code = SIGIO; saved_handlers[4].code = 0; #else saved_handlers[3].code = 0; #endif Shouldn't the else case initialize saved_handlers[4]? On the off chance it is garbage valued coincidentally as SIGALRM, the subsequent SIG_IGN could drop a pending SIGALRM. Peter, which OS do you run? What is USABLE_SIGIO in your src/config.h? --001a11c2a120ca04e404f37876d6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> Are you talking about a SIGALRM received during the e= xecution of
> do_pending_atimers, between run_timer's call to set= _alarm and
> do_pending_atimers's call to unblock_atimers? If so,= the SIGALRM
> should be held by the operating system during that period, and Emacs> won't be informed of the SIGALRM until unblock_atimers does its<= br>> thing. Sorry, I don't see how this would cause a timer to stop.=

I see you're right, because SIGALRM isn't specified with SIG_IG= N at
any point.

While verifying that, I found in sys_subshell:
=A0 struct save_signal saved_handlers[5];
=A0 [...]
#ifdef USABL= E_SIGIO
=A0 saved_handlers[3].code =3D SIGIO;
=A0 saved_handlers[4].code =3D 0;<= br>#else
=A0 saved_handlers[3].code =3D 0;
#endif

Shouldn'= t the else case initialize saved_handlers[4]? On the off
chance it is ga= rbage valued coincidentally as SIGALRM, the subsequent
SIG_IGN could drop a pending SIGALRM.

Peter, which OS do you run? Wh= at is USABLE_SIGIO in your src/config.h?

--001a11c2a120ca04e404f37876d6--