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" <
eliz@gnu.org> wrote:
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.