[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#19983: 24.4; exit-emacs regression in 24.4?

From: Eli Zaretskii
Subject: bug#19983: 24.4; exit-emacs regression in 24.4?
Date: Sun, 08 Mar 2015 18:14:17 +0200

Please always CC the bug address, so that this discussion gets
recorded with the bug.

> From: Sam Halliday <address@hidden>
> 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
> 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:

   (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)))"


  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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]