From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Reuben Thomas Newsgroups: gmane.emacs.bugs Subject: bug#28319: emacsclient tests interfere with running Emacs, hang Date: Tue, 5 Sep 2017 22:11:15 +0100 Message-ID: References: <9swp5iqsmt.fsf@fencepost.gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a113dc3aef2862f055877aae6" X-Trace: blaine.gmane.org 1504645946 7159 195.159.176.226 (5 Sep 2017 21:12:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 5 Sep 2017 21:12:26 +0000 (UTC) Cc: 28319@debbugs.gnu.org To: Glenn Morris Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Sep 05 23:12:11 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dpL8l-0001Dn-3R for geb-bug-gnu-emacs@m.gmane.org; Tue, 05 Sep 2017 23:12:11 +0200 Original-Received: from localhost ([::1]:33222 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dpL8q-0006OV-Mg for geb-bug-gnu-emacs@m.gmane.org; Tue, 05 Sep 2017 17:12:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54934) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dpL8h-0006OC-CE for bug-gnu-emacs@gnu.org; Tue, 05 Sep 2017 17:12:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dpL8c-0001ZA-Az for bug-gnu-emacs@gnu.org; Tue, 05 Sep 2017 17:12:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:43202) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dpL8c-0001YS-89 for bug-gnu-emacs@gnu.org; Tue, 05 Sep 2017 17:12:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dpL8b-000281-QT for bug-gnu-emacs@gnu.org; Tue, 05 Sep 2017 17:12:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Reuben Thomas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 05 Sep 2017 21:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28319 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 28319-submit@debbugs.gnu.org id=B28319.15046458848127 (code B ref 28319); Tue, 05 Sep 2017 21:12:01 +0000 Original-Received: (at 28319) by debbugs.gnu.org; 5 Sep 2017 21:11:24 +0000 Original-Received: from localhost ([127.0.0.1]:51883 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dpL80-000271-2f for submit@debbugs.gnu.org; Tue, 05 Sep 2017 17:11:24 -0400 Original-Received: from mail-oi0-f49.google.com ([209.85.218.49]:34231) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dpL7x-00026l-RS for 28319@debbugs.gnu.org; Tue, 05 Sep 2017 17:11:22 -0400 Original-Received: by mail-oi0-f49.google.com with SMTP id h70so32033735oic.1 for <28319@debbugs.gnu.org>; Tue, 05 Sep 2017 14:11:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sc3d.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BE4bf/0Lg9aHG+0OPSppf3ZLVrDa1fQXcU2FTeM1fkU=; b=yEHH0nsmgWs9y54I26xiFis08eRldU/GisQsbCKkQyBCDwW8pk0+YoIHixPTje7gQG YM7tSVDTFvp5ZT4Gkp5mcWuFod9q7WiQUFydZrqBU8jV04vwcNNc0W91C0EIIcVvNmEy bN89pcq5LdGUUVdvXHVhIySRjGT3Vc7licXqY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BE4bf/0Lg9aHG+0OPSppf3ZLVrDa1fQXcU2FTeM1fkU=; b=fW0AYxMmvnUwYxpFpxSvgDqHzubrzWyobao1zqPfiipHAA+xPfG3Ix4KdfwyxE3tL9 ndZwteuuz6bu01X7Ev5rbzGdlS1aDlt3yP7ptO0yzXVs2WSVw6E6BvIN4YqR+KWnx6Q2 jkWOkdotbtnTPVAHe56xlzqcwQSivhoSsdpZSpEiRRQO/3cFp80s5VVTlolmzpzv2YFw AE79w7nwoGTWSZGC/0VaGzubKrcCI0oE+cDtYtWxufs+xm5HCoyMNo1j4LPn4PgrL2nu g59aEg0mFUwSJJrvx1KByF+D2RtY8cRj++KcbDA2to0LaIBGJXt/p8GhTcXeENICA4Ob hhqQ== X-Gm-Message-State: AHPjjUjI/fFJd5Mog8Dsq6dUO8qxw9Sbmblpwt6Yr6Qz6m6vhNEBB41J 0uG6PJgCScbVhu4HqKi9mC7woFf26i+i X-Google-Smtp-Source: ADKCNb4GWWOVzgGVwWBbsk6vnDU3LIw1Dpr494ioVy1tpoctkA08emKMuItqDs6qgUO3iunS4Xa0JI9whSsCYqFwDQ4= X-Received: by 10.202.72.200 with SMTP id v191mr469647oia.139.1504645875920; Tue, 05 Sep 2017 14:11:15 -0700 (PDT) Original-Received: by 10.157.53.86 with HTTP; Tue, 5 Sep 2017 14:11:15 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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" Xref: news.gmane.org gmane.emacs.bugs:136619 Archived-At: --001a113dc3aef2862f055877aae6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 5 September 2017 at 20:55, Glenn Morris wrote: > > The tests still fail on hydra with "Profiling timer expired". > I can reproduce this locally if I configure with --enable-profiling. > =E2=80=8BThanks for the reproduction method, and for the tidy-up work you d= id on the tests; I can reproduce the "timer expired" problem. I see that --enable-profiling stops profiler.el from working, so it's nothing to do with profiler.el (this suggests incidentally that there's nothing I can do directly about the problem from Elisp, hence in the test code itself). I also see that the error message "Profiling timer expired" is caused by SIGPROF. Looking at the code in Emacs controlled by -DPROFILING (set to 1 by --enable-profiling), I find there's very little, but what there is seems to refer to the mon* routines, for which I find no man pages on my system, but a little searching online suggests are BSD-derived. I see that Emacs, in src/sysdep.c, sets SIGPROF's handler to SIG_IGN. So Emacs ignores the signal, but clearly from the call-process return value, it's being delivered to the emacsclient child process. The main thing I don't understand is why this behavior isn't a problem for other tests that use call-process, except that they don't seem to check the return value; but unlike the emacsclient test, at least some of them rely on some action having been taken by the called process, so presumably it must have completed successfully before receiving SIGPROF? If this is indeed the case, then the emacsclient test could simply allow the error message to signal success. Can you enlighten me any further? --=20 https://rrt.sc3d.org --001a113dc3aef2862f055877aae6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On 5= September 2017 at 20:55, Glenn Morris <rgm@gnu.org> wrote:

The tests still fail on hydra with "Profiling timer expired".
I can reproduce this locally if I configure with --enable-profiling.

=E2=80=8BThanks for the reproduction m= ethod, and for the tidy-up work you did on the tests; I can reproduce the &= quot;timer expired" problem.

I see that --enable-profiling stop= s profiler.el from working, so it's nothing to do with profiler.el (thi= s suggests incidentally that there's nothing I can do directly about th= e problem from Elisp, hence in the test code itself). I also see that the e= rror message "Profiling timer expired" is caused by SIGPROF. Look= ing at the code in Emacs controlled by -DPROFILING (set to 1 by --enable-pr= ofiling), I find there's very little, but what there is seems to refer = to the mon* routines, for which I find no man pages on my system, but a lit= tle searching online suggests are BSD-derived.

I see that Emacs, in = src/sysdep.c, sets SIGPROF's handler to SIG_IGN. So Emacs ignores the s= ignal, but clearly from the call-process return value, it's being deliv= ered to the emacsclient child process.

The main thing I don't un= derstand is why this behavior isn't a problem for other tests that use = call-process, except that they don't seem to check the return value; bu= t unlike the emacsclient test, at least some of them rely on some action ha= ving been taken by the called process, so presumably it must have completed= successfully before receiving SIGPROF? If this is indeed the case, then th= e emacsclient test could simply allow the error message to signal success.<= /div>

Can you enlighten me any further= ?

--
--001a113dc3aef2862f055877aae6--