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

[Sam Halliday <sam.halliday@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4187 bytes --]

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.
>

[-- Attachment #2: Type: text/html, Size: 5401 bytes --]