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.
Please always CC the bug address, so that this discussion gets
recorded with the bug.
> From: Sam Halliday <sam.halliday@gmail.com>
> 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.