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

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

[Sam Halliday]

Hi,

When running our emacs integration tests across the matrix of all
emacs24 versions, we get a bizarre failure where our test suite reports
an exit 0, but the emacs application exits with 1.

This only happens in emacs-24.4 and is very repeatable

More details, including a link to failing builds and our source code is
available on our bug tracker, as well as a suspicious commit in emacs
regarding EOL in stdin:

  https://github.com/ensime/ensime-server/issues/862

Of immediate concern to us is finding a workaround, is there something
we can do to recover the original behaviour? Bleeding stdin, or piping
some text to stdin?

-- 
Best regards,
Sam

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

[Eli Zaretskii]

> From: Sam Halliday <sam.halliday@gmail.com>
> Date: Mon, 02 Mar 2015 22:38:42 +0000
> 
> When running our emacs integration tests across the matrix of all
> emacs24 versions, we get a bizarre failure where our test suite reports
> an exit 0, but the emacs application exits with 1.
> 
> This only happens in emacs-24.4 and is very repeatable
> 
> More details, including a link to failing builds and our source code is
> available on our bug tracker, as well as a suspicious commit in emacs
> regarding EOL in stdin:
> 
>   https://github.com/ensime/ensime-server/issues/862
> 
> Of immediate concern to us is finding a workaround, is there something
> we can do to recover the original behaviour? Bleeding stdin, or piping
> some text to stdin?

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.

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

[Eli Zaretskii]

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.

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

[Sam Halliday]

[-- 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 --]

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

[Eli Zaretskii]

> Date: Sun, 8 Mar 2015 16:26:24 +0000
> From: Sam Halliday <sam.halliday@gmail.com>
> Cc: 19983@debbugs.gnu.org
> 
> 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. 

Thanks, that will be useful indeed.

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

[Sam Halliday]

Hi Eli,

Eli Zaretskii <eliz@gnu.org> writes:
>> 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. 
>
> Thanks, that will be useful indeed.

I've not got the bisection working yet (coming next) but I have isolated
the problem to a smaller part of our testsuite! That may help you to
guess further at what is going wrong.

It looks like the return value is flipped from 0 to 1 only when I run
our external `sbt` script as part of the test:

https://github.com/ensime/ensime-emacs/blob/master/ensime-startup.el#L162

which is using the `process' feature.

Any of this sounding suspicious wrt 24.4?

Unfortunately, that still means that in order to run our tests locally
you'd need to install a JDK and the sbt script, so I'll get onto
bisecting.

-- 
Best regards,
Sam

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

[Eli Zaretskii]

> From: Sam Halliday <sam.halliday@gmail.com>
> Cc: 19983@debbugs.gnu.org
> Date: Sun, 08 Mar 2015 18:34:19 +0000
> 
> It looks like the return value is flipped from 0 to 1 only when I run
> our external `sbt` script as part of the test:
> 
> https://github.com/ensime/ensime-emacs/blob/master/ensime-startup.el#L162
> 
> which is using the `process' feature.
> 
> Any of this sounding suspicious wrt 24.4?

No, sorry.

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

[Sam Halliday]

Eli,

One small bit of immediate feedback from the bisection (still running)
is that commit 7932d062cf85c2c37bd15b22be30a65c034001fc does *NOT* fix
the bug that we are seeing.

Best regards,
Sam

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sun, 8 Mar 2015 16:26:24 +0000
>> From: Sam Halliday <sam.halliday@gmail.com>
>> Cc: 19983@debbugs.gnu.org
>> 
>> 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. 
>
> Thanks, that will be useful indeed.

-- 
Best regards,
Sam

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

[Eli Zaretskii]

> From: Sam Halliday <sam.halliday@gmail.com>
> Cc: 19983@debbugs.gnu.org
> Date: Sun, 08 Mar 2015 19:11:42 +0000
> 
> One small bit of immediate feedback from the bisection (still running)
> is that commit 7932d062cf85c2c37bd15b22be30a65c034001fc does *NOT* fix
> the bug that we are seeing.

I'm not surprised.  Thanks.

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

[Sam Halliday]

Hi Eli,

Eli Zaretskii <eliz@gnu.org> writes:
>> Hmm. I might try setting up a disectian of the emacs commits
> Thanks, that will be useful indeed.

5f53d2441abf6eafe8e14f29d73e14afe8bec35f is the first bad commit
commit 5f53d2441abf6eafe8e14f29d73e14afe8bec35f
Author: HIROSHI OOTA <nil@mad.dog.cx>
Date:   Wed Jan 25 13:35:05 2012 +0800

    * src/coding.c (encode_designation_at_bol): Change return value to EMACS_INT.


But this may be only an approximation, as there are a few commits where
it is not possible to compile emacs and in those cases I flagged them as
"good".

I hope that's useful!


-- 
Best regards,
Sam

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

[Óscar Fuentes]

Sam Halliday <sam.halliday@gmail.com> writes:

> But this may be only an approximation, as there are a few commits where
> it is not possible to compile emacs and in those cases I flagged them as
> "good".

"git bisect skip" is much better on that case.

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

[Eli Zaretskii]

> From: Sam Halliday <sam.halliday@gmail.com>
> Cc: 19983@debbugs.gnu.org
> Date: Sun, 08 Mar 2015 22:57:42 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> >> Hmm. I might try setting up a disectian of the emacs commits
> > Thanks, that will be useful indeed.
> 
> 5f53d2441abf6eafe8e14f29d73e14afe8bec35f is the first bad commit
> commit 5f53d2441abf6eafe8e14f29d73e14afe8bec35f
> Author: HIROSHI OOTA <nil@mad.dog.cx>
> Date:   Wed Jan 25 13:35:05 2012 +0800
> 
>     * src/coding.c (encode_designation_at_bol): Change return value to EMACS_INT.
> 
> 
> But this may be only an approximation, as there are a few commits where
> it is not possible to compile emacs and in those cases I flagged them as
> "good".

Can you show the two commits, a "bad" one and a "good" one, around
5f53d2441abf6eafe8e14f29d73e14afe8bec35f, such that you actually built
and tested those two?

Thanks.

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

[Glenn Morris]

Sam Halliday wrote:

> 5f53d2441abf6eafe8e14f29d73e14afe8bec35f is the first bad commit

This commit first appeared in Emacs 23.4.

This makes no sense, since you previously said that the issue (whatever
it actually is) was not present in 24.1, 24.2, or 24.3. So why are you
even bisecting over such old revisions? You might want to repeat your
bisection but only over the range corresponding to the 24.3 and 24.4
releases.

(Personally I think this report is suffering from a lack of a minimal
reproducible example.)

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

[Sam Halliday]

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

Yeah it's weird. I asked git to stay between 24.4 (bad) and 24.3 (good). I
tried it again with return 155 but again it jumped outside the bound.

I'll have to read up on cut biscect. It's not behaving as expected.

A minimal reproducible case would certainly get the thanks of my
ludicrously overheated CPUs right about now! :-P
On 10 Mar 2015 19:30, "Glenn Morris" <rgm@gnu.org> wrote:

> Sam Halliday wrote:
>
> > 5f53d2441abf6eafe8e14f29d73e14afe8bec35f is the first bad commit
>
> This commit first appeared in Emacs 23.4.
>
> This makes no sense, since you previously said that the issue (whatever
> it actually is) was not present in 24.1, 24.2, or 24.3. So why are you
> even bisecting over such old revisions? You might want to repeat your
> bisection but only over the range corresponding to the 24.3 and 24.4
> releases.
>
> (Personally I think this report is suffering from a lack of a minimal
> reproducible example.)
>

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

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

[Sam Halliday]

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

Hi all,

With logic added to my script to skip bad builds, I get the following,
which is really confusing because the emacs-24.3 tag is Sun Mar 10 2013
and this is well before that. It's part of some epic merge at some
point, and I think git just fails to calculate the correct steps between
the two tags. Any suggestions for a better bound to check within that
won't confuse git so much? What the earliest parent commit for the 24.4
branch before the 24.3 code freezes?


================================================================
052f924a01f8a65ca0bfc9e6584302613e019489 is the first bad commit
commit 052f924a01f8a65ca0bfc9e6584302613e019489
Author: Chong Yidong <cyd@gnu.org>
Date:   Fri Nov 2 08:48:12 2012 +0800

    Bump version to 24.3.50

:100644 100644 2c50c5bbb91174367246f5e585a31265b001d68d 9153c656dbea20eb462f32830da09b180e2df92a M	README
:100644 100644 4564bc3085e3413b69595794c8cb6eca58af6002 b0711923e1a0024cc522d059fc3a30e9b0fb9775 M	configure.ac
:040000 040000 25ee22b3e1847fe28470188ca03bffdbcfc694cd c4bb600a6d1910112edc713c5ce5ff002ca95e4c M	doc
:040000 040000 43eda55478723dc07364848fec466c7eb76cb0d3 665f36f085d3d792a6d29310dd00eb8ac044f3ee M	msdos
:040000 040000 c4ecb38213739ee30d8701454ef8bbbbfceb8f51 a2005bb04895d7d6070456aaaef9a710e34b1462 M	nt
bisect run success
================================================================

# bad: [83bad90efe943e7c88431b7a71bc1d5cf1304c92] Add 24.4 release ChangeLog entries
# good: [24958590a00900371b6b3b154fc1df5c980d056c] Add 24.3 release to ChangeLogs
git bisect start 'emacs-24.4' 'emacs-24.3'
# skip: [dd4f8b743d6c3f5f59e5afeca813c13619a0a771] * lisp/progmodes/cc-mode.el: Minor cleanup of var declarations. (c-define-abbrev-table): Add `doc' argument. (c-mode-abbrev-table, c++-mode-abbrev-table) (objc-mode-abbrev-table, java-mode-abbrev-table) (idl-mode-abbrev-table, pike-mode-abbrev-table) (awk-mode-abbrev-table): Use it. (c-mode-syntax-table, c-mode-map, c++-mode-syntax-table) (c++-mode-map, objc-mode-syntax-table, objc-mode-map) (java-mode-syntax-table, java-mode-map, idl-mode-syntax-table) (idl-mode-map, pike-mode-syntax-table, pike-mode-map, awk-mode-map): Move initialization into the declaration; and remove any autoload cookie.
git bisect skip dd4f8b743d6c3f5f59e5afeca813c13619a0a771
# bad: [91b982a0355d6eff74f7d9df56d5b321b13d2f8a] * progmodes/grep.el (rgrep): Escape command line.  Sometimes, it is too long for Tramp.  See discussion in <http://thread.gmane.org/gmane.emacs.tramp/8233/focus=8244>.
git bisect bad 91b982a0355d6eff74f7d9df56d5b321b13d2f8a
# bad: [4a9204fe04dee76dd067aaf1b078a777d1bb1a91] * callproc.c (Fcall_process): Don't misreport vfork failure.
git bisect bad 4a9204fe04dee76dd067aaf1b078a777d1bb1a91
# bad: [b24696b8c857f76f4fa5769578e9b8db279a2aa8] nt/config.nt: Sync with autogen/config.in. (GETGROUPS_T, GETGROUPS_ZERO_BUG, GNULIB_FACCESSAT, HAVE_ACCESS) (HAVE_EACCESS, HAVE_FACCESSAT, HAVE_GETGROUPS, HAVE_LIBGEN_H): New macros.
git bisect bad b24696b8c857f76f4fa5769578e9b8db279a2aa8
# skip: [79b3e3765638652130d01dc083fdbfa2efc0092c] * lisp/progmodes/perl-mode.el (perl-prettify-symbols): New defcustom. (perl--prettify-symbols-alist): New const. (perl--font-lock-compose-symbol, perl--font-lock-symbols-keywords): New funs. (perl-font-lock-keywords-2): Use them. (perl-electric-noindent-p): New function. (perl-mode): Use it to set up electric-indent-mode. (perl-electric-terminator, perl-indent-command): Mark obsolete. (perl-mode-map): Remove bindings for them. (perl-imenu-generic-expression, perl-outline-level): Match functions&packages in column>0.
git bisect skip 79b3e3765638652130d01dc083fdbfa2efc0092c
# bad: [f5925cd9f5e525c1e023c163338ccbf6c19e9ef0] * lisp/emacs-lisp/bytecomp.el (byte-compile-out-toplevel): Don't turn (funcall '(lambda ..) ..) into ((lambda ..) ..).
git bisect bad f5925cd9f5e525c1e023c163338ccbf6c19e9ef0
# bad: [89bc059271bd3d7c62314a05664b111705c4bec9] * window.c (quad): New function. (Fwindow_edges, Fwindow_pixel_edges, Fwindow_inside_edges) (Fwindow_absolute_pixel_edges, Fwindow_inside_absolute_pixel_edges) (Fwindow_inside_pixel_edges, Fpos_visible_in_window_p) (Fwindow_line_height): Use it. (Fwindow_fringes): Use list3. (Fwindow_scroll_bars): Use list4. (Fwindow_frame, Fwindow_top_child, Fwindow_left_child) (Fwindow_combination_limit): Allow zero number of arguments.
git bisect bad 89bc059271bd3d7c62314a05664b111705c4bec9
# bad: [f58542e1510319921d1745e0ad647ed42b1157f2] Merge from emacs-24; up to 2012-11-03T05:11:34Z!dmantipov@yandex.ru
git bisect bad f58542e1510319921d1745e0ad647ed42b1157f2
# bad: [00a3b041730e178fe68850b76ac4216af62ea606] No need for filecache.el to load find-lisp when compiling
git bisect bad 00a3b041730e178fe68850b76ac4216af62ea606
# bad: [1005b4b98a43c4aea2ac8f01a5743b6b38bdd964] Implement backtrace output for fatal errors on MS-Windows.
git bisect bad 1005b4b98a43c4aea2ac8f01a5743b6b38bdd964
# bad: [2b371ff75d64fb34466119e33f5cbb2c5eb27364] Remove pad from struct input_event. * termhooks.h (struct input_event): Remove padding field. Adjust comment. * keyboard.c (event_to_kboard): Simplify because frame_or_window member is never cons for a long time.  Adjust comment. (mark_kboards): Adjust because SELECTION_REQUEST_EVENT and SELECTION_CLEAR_EVENT has no Lisp_Objects to mark.  Add comment. * xterm.c (handle_one_xevent): Do not initialize frame_or_window field of SELECTION_REQUEST_EVENT and SELECTION_CLEAR_EVENT.
git bisect bad 2b371ff75d64fb34466119e33f5cbb2c5eb27364
# bad: [052f924a01f8a65ca0bfc9e6584302613e019489] Bump version to 24.3.50
git bisect bad 052f924a01f8a65ca0bfc9e6584302613e019489
# first bad commit: [052f924a01f8a65ca0bfc9e6584302613e019489] Bump version to 24.3.50





[-- Attachment #2.1: Type: text/plain, Size: 1062 bytes --]

Sam Halliday <sam.halliday@gmail.com> writes:

> Yeah it's weird. I asked git to stay between 24.4 (bad) and 24.3 (good). I
> tried it again with return 155 but again it jumped outside the bound.
>
> I'll have to read up on cut biscect. It's not behaving as expected.
>
> A minimal reproducible case would certainly get the thanks of my
> ludicrously overheated CPUs right about now! :-P
> On 10 Mar 2015 19:30, "Glenn Morris" <rgm@gnu.org> wrote:
>
>> Sam Halliday wrote:
>>
>> > 5f53d2441abf6eafe8e14f29d73e14afe8bec35f is the first bad commit
>>
>> This commit first appeared in Emacs 23.4.
>>
>> This makes no sense, since you previously said that the issue (whatever
>> it actually is) was not present in 24.1, 24.2, or 24.3. So why are you
>> even bisecting over such old revisions? You might want to repeat your
>> bisection but only over the range corresponding to the 24.3 and 24.4
>> releases.
>>
>> (Personally I think this report is suffering from a lack of a minimal
>> reproducible example.)
>>

-- 
Best regards,
Sam

[-- Attachment #2.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 180 bytes --]

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

[Eli Zaretskii]

> From: Sam Halliday <sam.halliday@gmail.com>
> Cc: 19983@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
> Date: Tue, 10 Mar 2015 23:17:39 +0000
> 
> With logic added to my script to skip bad builds, I get the following,
> which is really confusing because the emacs-24.3 tag is Sun Mar 10 2013
> and this is well before that.

Am I blind, or are there no "good" commits in this trace, except the
one in the beginning?

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

[Glenn Morris]

Sam Halliday wrote:

> With logic added to my script to skip bad builds, I get the following,
> which is really confusing because the emacs-24.3 tag is Sun Mar 10 2013
> and this is well before that. It's part of some epic merge at some
> point, and I think git just fails to calculate the correct steps between
> the two tags. Any suggestions for a better bound to check within that
> won't confuse git so much? What the earliest parent commit for the 24.4
> branch before the 24.3 code freezes?

Oh right, the 24.3 and 24.4 releases came from different branches.
Hmm. 24.4 came from the current "emacs-24" branch, so I think you should
be working with that branch rather than "master", if you aren't already.
Your end point should be the revision tagged "emacs-24.4", which should
test as bad.

24.3 came from a different emacs-24 branch, onto which the current
emacs-24 branch was destructively pushed (yay). I think this means that
your start point should be the revision at which the 24.3 and 24.4
branches diverged, which I think is
052f924a01f8a65ca0bfc9e6584302613e019489 on the current "emacs-24"
branch, which should test as good.

I have no idea how you are supposed to figure that out from first
principles...

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

[Sam Halliday]

Thanks Glenn,

>> ... weird bisecting results ...
>
> 24.3 came from a different emacs-24 branch, onto which the current
> emacs-24 branch was destructively pushed (yay). I think this means that
> your start point should be the revision at which the 24.3 and 24.4
> branches diverged, which I think is
> 052f924a01f8a65ca0bfc9e6584302613e019489 on the current "emacs-24"
> branch, which should test as good.

Unfortunately, it looks like 052f924a01f8a65ca0bfc9e6584302613e019489 is
bad. This commit seems to be older than 24.3 (emacs has a dev versioning
convention that I don't understand). Is there another root that I could
go back to? The point at which 24.3 and 24.4 have in common?

I'll try it a couple of more times. It could be a random failure.

Once I track down the offending commit, I'll see if I can guess what the
problem is and make a minimal test. I suspect it has something to do
with process handling. At the moment, building the emacs docs every
commit is the bottleneck, not my test. Is there any way to build/install
without the docs (or compiling the .elc files).


-- 
Best regards,
Sam

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

[Glenn Morris]

Sam Halliday wrote:

> Unfortunately, it looks like 052f924a01f8a65ca0bfc9e6584302613e019489 is
> bad. This commit seems to be older than 24.3 (emacs has a dev versioning
> convention that I don't understand). Is there another root that I could
> go back to? The point at which 24.3 and 24.4 have in common?

That's what I thought I gave you... Maybe I goofed.
I'm sure our resident git experts will tell us the right answer.

> with process handling. At the moment, building the emacs docs every
> commit is the bottleneck, not my test. Is there any way to build/install
> without the docs (or compiling the .elc files).

For bisecting, I use:

[ -e Makefile ] && make maintainer-clean
./autogen.sh
./configure --without-all --cache-file=/tmp/config.cache
make -C lib all
make -C src bootstrap-emacs
make -C src emacs

(with suitable -j# and error trapping at each stage).

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

[Andreas Schwab]

Sam Halliday <sam.halliday@gmail.com> writes:

> ================================================================
> 052f924a01f8a65ca0bfc9e6584302613e019489 is the first bad commit
> commit 052f924a01f8a65ca0bfc9e6584302613e019489
> Author: Chong Yidong <cyd@gnu.org>
> Date:   Fri Nov 2 08:48:12 2012 +0800
>
>     Bump version to 24.3.50

That may mean that you misattributed one of the steps.  Perhaps the
failure condition actually depends on external events?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Sam Halliday]

Andreas Schwab writes:
>> ================================================================
>> 052f924a01f8a65ca0bfc9e6584302613e019489 is the first bad commit
>
> That may mean that you misattributed one of the steps.  Perhaps the
> failure condition actually depends on external events?

That was a PEBCAK :-)

Running again, this commit is good. Hopefully we'll have our answer in
the next few hours.


-- 
Best regards,
Sam

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

[Sam Halliday]

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

This is far too sporadic,feel free to close. There is definitely something
funky going on but it seems to only be triggered by an intricate
combination of non-trivial exit hooks, emacs 24.4 and a process that runs
to completion.
On 14 Mar 2015 10:36, "Sam Halliday" <sam.halliday@gmail.com> wrote:

> Andreas Schwab writes:
> >> ================================================================
> >> 052f924a01f8a65ca0bfc9e6584302613e019489 is the first bad commit
> >
> > That may mean that you misattributed one of the steps.  Perhaps the
> > failure condition actually depends on external events?
>
> That was a PEBCAK :-)
>
> Running again, this commit is good. Hopefully we'll have our answer in
> the next few hours.
>
>
> --
> Best regards,
> Sam
>

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

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

[Andreas Schwab]

Sam Halliday <sam.halliday@gmail.com> writes:

> But this may be only an approximation, as there are a few commits where
> it is not possible to compile emacs and in those cases I flagged them as
> "good".

You should mark them as "skip".

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."