From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Sam Halliday Newsgroups: gmane.emacs.bugs Subject: bug#19983: 24.4; exit-emacs regression in 24.4? Date: Sun, 8 Mar 2015 16:26:24 +0000 Message-ID: References: <87pp8rc9e5.fsf@gmail.com> <83egp6qef7.fsf@gnu.org> <87k2yrvea4.fsf@gmail.com> <83d24jlb52.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bdca5b6eff1fb0510c9601c X-Trace: ger.gmane.org 1425832045 16163 80.91.229.3 (8 Mar 2015 16:27:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 8 Mar 2015 16:27:25 +0000 (UTC) Cc: 19983@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Mar 08 17:27:16 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 1YUe2o-0006kO-PN for geb-bug-gnu-emacs@m.gmane.org; Sun, 08 Mar 2015 17:27:11 +0100 Original-Received: from localhost ([::1]:39634 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YUe2o-00064B-23 for geb-bug-gnu-emacs@m.gmane.org; Sun, 08 Mar 2015 12:27:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56207) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YUe2k-00063D-1M for bug-gnu-emacs@gnu.org; Sun, 08 Mar 2015 12:27:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YUe2g-0008MK-Lt for bug-gnu-emacs@gnu.org; Sun, 08 Mar 2015 12:27:05 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:40987) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YUe2g-0008MG-IL for bug-gnu-emacs@gnu.org; Sun, 08 Mar 2015 12:27:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YUe2g-0005sy-56 for bug-gnu-emacs@gnu.org; Sun, 08 Mar 2015 12:27:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Sam Halliday Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 08 Mar 2015 16:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19983 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 19983-submit@debbugs.gnu.org id=B19983.142583199522578 (code B ref 19983); Sun, 08 Mar 2015 16:27:02 +0000 Original-Received: (at 19983) by debbugs.gnu.org; 8 Mar 2015 16:26:35 +0000 Original-Received: from localhost ([127.0.0.1]:39555 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YUe2E-0005s5-Nd for submit@debbugs.gnu.org; Sun, 08 Mar 2015 12:26:35 -0400 Original-Received: from mail-ie0-f177.google.com ([209.85.223.177]:35896) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YUe2B-0005ro-5d for 19983@debbugs.gnu.org; Sun, 08 Mar 2015 12:26:32 -0400 Original-Received: by iecar1 with SMTP id ar1so1831374iec.3 for <19983@debbugs.gnu.org>; Sun, 08 Mar 2015 09:26:24 -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=3VT8BIypsusD4qmDp1E0IM7UtwCjW7KjrvnQHbOLSqQ=; b=tbsT1xODHgO6SWs3NuhndCh9IIpRAzTCpDbp173VHiB6xo2Zje3zdKA35Ieky5WVJC 7uW6dC1ausy+heEc3+23HWxR9nTH9Z5RIj9TVWWUx9EM/1SdT9VXjoFyzvf7TgehZDsr FFBBkzgBx5HAbxspdu45BqTUFBM/tbfnX0qvliRqscK/xzNkGusHIS39QSk5MpgD9K8f Qc5Ixt6abYD+jL8S13QWLZmkXuP8AlYFyIdDHhNvhRUcAcH6y53KtpGPaG6uJMsgNzES lvxAQ0j2ZgXnsslVwM5TpcZZIYPoQanUVN+Y5OpHIBgCdCGdjFsVtv2wTmWGCZhVS5/n DOuA== X-Received: by 10.50.49.43 with SMTP id r11mr68790558ign.18.1425831984324; Sun, 08 Mar 2015 09:26:24 -0700 (PDT) Original-Received: by 10.36.39.203 with HTTP; Sun, 8 Mar 2015 09:26:24 -0700 (PDT) Original-Received: by 10.36.39.203 with HTTP; Sun, 8 Mar 2015 09:26:24 -0700 (PDT) In-Reply-To: <83d24jlb52.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: 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:100272 Archived-At: --047d7bdca5b6eff1fb0510c9601c Content-Type: text/plain; charset=UTF-8 Hmm. I might try setting up a disectian of the emacs commits on a machine with the environment. That will at least let us know which emacs commit introduced the regression. On 8 Mar 2015 16:14, "Eli Zaretskii" wrote: > Please always CC the bug address, so that this discussion gets > recorded with the bug. > > > From: Sam Halliday > > Date: Sun, 08 Mar 2015 12:56:19 +0000 > > > > > Can you please show a complete self-contained recipe for reproducing > > > the problem, starting with "emacs -Q"? I couldn't find one in the URL > > > you provide above; apologies if I missed something. > > > > > > Yes, (our test suite intentionally creates a clean room), but apologies > > in advance because this involves a lot of automatic downloading of Java > > / Scala jars that will probably be completely irrelevant to you other > > than this bug report. But I'll explain to you what is happening and how > > to clean up afterwards. > > > > If you clone our repository > > > > git clone --depth 1 https://github.com/ensime/ensime-emacs > > > > you can run the tests with > > > > test/run_emacs_tests.sh > > > > That will create a clean-room emacs.d just for the tests and contact > > MELPA to download our dependencies. > > > > HOWEVER, you will also need to have a working JDK and the `sbt` script > > in your PATH. 1) Use your package manager to install something like > > `openjdk-6-jdk` 2) obtain > > https://github.com/paulp/sbt-extras/blob/master/sbt and place it on your > > PATH. > > > > To explain: ENSIME is a bit like SLIME. There is a server component > > which runs a Scala compiler in-process. Scala runs on the JVM and we > > piggy-back off the SBT build tool for dependency management. Lots of > > files are being downloaded and being placed into your `~/.ivy` and > > `~/.sbt` folders as a result. For the typical Scala developer, this will > > already have been populated because its part of their dev environment. > > > > When we run the tests in emacs 24.1, 24.2, 24.3 the tests exit 0. But > > with 24.4 they exit 1 (despite us printing out on the screen "exiting > > 0"). We have absolutely no idea what is going on, but it really feels > > like a regression in emacs 24.4. We are primarily interested in a > > workaround at this stage, but obviously if this is a bug in emacs > > itself, I think we'd all like to see a fix. > > > > The code that is calling `kill-emacs` is here > > https://github.com/ensime/ensime-emacs/blob/master/ensime-test.el#L402 > > > > If you'd like to continue discussing by email that is fine, but you'll > > probably get a faster response on > > https://github.com/ensime/ensime-server/issues/862 as I cannot access my > > personal email from my work account. > > > > We really wish we had a more minimal test for you, but of course > > anything involving `kill-emacs` works just fine in trivial scripts. > > I'm sorry, I cannot afford to re-create your environment on my > system. I tried to simplify the situation as follows: > > The code around line 402 in the above repository is this: > > (progn > (goto-char (point-max)) > (let* ((status (if ensime--test-had-failures 1 0)) > (msg (format "Finished suite with status %s." status))) > (message msg) > (when ensime--test-exit-on-finish > (kill-emacs status)))) > > I emulated that with the following: > > emacs -batch --eval "(progn (let ((status 0)) (message \"Status %s\" > status) (kill-emacs status)))" > > and > > emacs -batch --eval "(progn (let ((status 1)) (message \"Status %s\" > status) (kill-emacs status)))" > > In both cases, I saw the message announcing the value of exit status, > and Emacs exited exactly with the status I wanted it to. > > So I'm sorry to say that I couldn't reproduce the problem you are > reporting. > > What I can suggest is run Emacs under a debugger, put a breakpoint in > Fkill_emacs, and when it breaks, show what argument is received by > that function. > > Another possibility is that this is a manifestation of Bug#19897 that > was recently fixed on master. (But in that case, I cannot understand > why you didn't see it in 24.3, since that bug was VERY old. > --047d7bdca5b6eff1fb0510c9601c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hmm. I might try setting up a disectian of the emacs commits= on a machine with the environment. That will at least let us know which em= acs commit introduced the regression.

On 8 Mar 2015 16:14, "Eli Zaretskii" &= lt;eliz@gnu.org> wrote:
Please always CC the bug address= , so that this discussion gets
recorded with the bug.

> From: Sam Halliday <sam.h= alliday@gmail.com>
> Date: Sun, 08 Mar 2015 12:56:19 +0000
>
> > Can you please show a complete self-contained recipe for reproduc= ing
> > the problem, starting with "emacs -Q"?=C2=A0 I couldn&#= 39;t find one in the URL
> > you provide above; apologies if I missed something.
>
>
> Yes, (our test suite intentionally creates a clean room), but apologie= s
> in advance because this involves a lot of automatic downloading of Jav= a
> / Scala jars that will probably be completely irrelevant to you other<= br> > than this bug report. But I'll explain to you what is happening an= d how
> to clean up afterwards.
>
> If you clone our repository
>
>=C2=A0 =C2=A0git clone --depth 1 https://github.com/ensime/ensime-emacs >
> you can run the tests with
>
>=C2=A0 =C2=A0test/run_emacs_tests.sh
>
> That will create a clean-room emacs.d just for the tests and contact > MELPA to download our dependencies.
>
> HOWEVER, you will also need to have a working JDK and the `sbt` script=
> in your PATH. 1) Use your package manager to install something like > `openjdk-6-jdk` 2) obtain
> https://github.com/paulp/sbt-extras/blob/master/sbt and pla= ce it on your
> PATH.
>
> To explain: ENSIME is a bit like SLIME. There is a server component > which runs a Scala compiler in-process. Scala runs on the JVM and we > piggy-back off the SBT build tool for dependency management. Lots of > files are being downloaded and being placed into your `~/.ivy` and
> `~/.sbt` folders as a result. For the typical Scala developer, this wi= ll
> already have been populated because its part of their dev environment.=
>
> When we run the tests in emacs 24.1, 24.2, 24.3 the tests exit 0. But<= br> > with 24.4 they exit 1 (despite us printing out on the screen "exi= ting
> 0"). We have absolutely no idea what is going on, but it really f= eels
> like a regression in emacs 24.4. We are primarily interested in a
> workaround at this stage, but obviously if this is a bug in emacs
> itself, I think we'd all like to see a fix.
>
> The code that is calling `kill-emacs` is here
> https://github.com/ensime/ensime-emacs/blob/= master/ensime-test.el#L402
>
> If you'd like to continue discussing by email that is fine, but yo= u'll
> probably get a faster response on
> https://github.com/ensime/ensime-server/issues/862 as I can= not access my
> personal email from my work account.
>
> We really wish we had a more minimal test for you, but of course
> anything involving `kill-emacs` works just fine in trivial scripts.
I'm sorry, I cannot afford to re-create your environment on my
system.=C2=A0 I tried to simplify the situation as follows:

The code around line 402 in the above repository is this:

=C2=A0(progn
=C2=A0 =C2=A0(goto-char (point-max))
=C2=A0 =C2=A0(let* ((status (if ensime--test-had-failures 1 0))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (msg (format "Finished suite with s= tatus %s." status)))
=C2=A0 =C2=A0 =C2=A0(message msg)
=C2=A0 =C2=A0 =C2=A0(when ensime--test-exit-on-finish
=C2=A0 =C2=A0 =C2=A0(kill-emacs status))))

I emulated that with the following:

=C2=A0 emacs -batch --eval "(progn (let ((status 0)) (message \"S= tatus %s\" status) (kill-emacs status)))"

and

=C2=A0 emacs -batch --eval "(progn (let ((status 1)) (message \"S= tatus %s\" status) (kill-emacs status)))"

In both cases, I saw the message announcing the value of exit status,
and Emacs exited exactly with the status I wanted it to.

So I'm sorry to say that I couldn't reproduce the problem you are reporting.

What I can suggest is run Emacs under a debugger, put a breakpoint in
Fkill_emacs, and when it breaks, show what argument is received by
that function.

Another possibility is that this is a manifestation of Bug#19897 that
was recently fixed on master.=C2=A0 (But in that case, I cannot understand<= br> why you didn't see it in 24.3, since that bug was VERY old.
--047d7bdca5b6eff1fb0510c9601c--