bug#21982: 25.1.50; Building emacs-25 branch fails

bug#21982: 25.1.50; Building emacs-25 branch fails

[Michael Heerdegen]

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


Hello,

bootstrapping a checkout of the emacs25 branch fails for me.  master
builds fine.

Here is what I did: I checked out the emacs-25 branch, I have a clean
worktree.  Then ./autogen.sh, ./configure, make bootstrap.

Here are the final lines of output that "make bootstrap" gave before it
died:


[-- Attachment #2: output.txt --]
[-- Type: text/plain, Size: 1519 bytes --]

Loading /home/micha/software/emacs/lisp/tooltip.el (source)...
Finding pointers to doc strings...
Finding pointers to doc strings...done
Dumping under the name emacs
91330 pure bytes used
: paxctl -zex emacs
mv -f emacs bootstrap-emacs
make -C ../lisp compile-first EMACS="../src/bootstrap-emacs"
make[3]: Entering directory '/home/micha/software/emacs/lisp'
  ELC      emacs-lisp/macroexp.elc
  ELC      emacs-lisp/cconv.elc
  ELC      emacs-lisp/byte-opt.elc
  ELC      emacs-lisp/bytecomp.elc
  ELC      emacs-lisp/autoload.elc
make[3]: Leaving directory '/home/micha/software/emacs/lisp'
make -C ../lisp autoloads EMACS="../src/bootstrap-emacs"
make[3]: Entering directory '/home/micha/software/emacs/lisp'
  GEN      calendar/cal-loaddefs.el
  GEN      calendar/diary-loaddefs.el
  GEN      calendar/hol-loaddefs.el
  GEN      mh-e/mh-loaddefs.el
  GEN      net/tramp-loaddefs.el
Directories for loaddefs: . ./calc ./calendar ./cedet ./cedet/ede ./cedet/semantic ./cedet/semantic/analyze ./cedet/semantic/bovine ./cedet/semantic/decorate ./cedet/semantic/symref ./cedet/semantic/wisent ./cedet/srecode ./emacs-lisp ./emacs-parallel ./emulation ./erc ./eshell ./gnus ./international ./language ./leim ./leim/ja-dic ./leim/quail ./mail ./mh-e ./net ./nxml ./org ./play ./progmodes ./textmodes ./url ./vc
  GEN      loaddefs.el
Making generated-autoload-file local to  *autoload-file* while let-bound!
*** Error in `../src/bootstrap-emacs': realloc(): invalid next size: 0x00000000046edaf0 ***
Fatal error 6: Aborted

[-- Attachment #3: Type: text/plain, Size: 773 bytes --]


Minor issue: after that had failed, I had to delete several lock files
by hand.

I'm reporting from the same environment with a master build.


Thanks,

Michael.



In GNU Emacs 25.1.50.1 (x86_64-pc-linux-gnu, GTK+ Version 3.18.2)
 of 2015-11-22
Repository revision: ea78129522f428888607151e4f91ade1f4839f3f
Windowing system distributor 'The X.Org Foundation', version 11.0.11703000
System Description:	Debian GNU/Linux testing (stretch)

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GSETTINGS NOTIFY
LIBXML2 FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11

Important settings:
  value of $LC_ALL: de_DE.utf8
  value of $LC_COLLATE: C
  value of $LC_TIME: C
  value of $LANG: de_DE.utf8
  locale-coding-system: utf-8-unix

Major mode: Emacs-Lisp

bug#21982: 25.1.50; Building emacs-25 branch fails

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Date: Sun, 22 Nov 2015 18:58:30 +0100
> 
> Directories for loaddefs: . ./calc ./calendar ./cedet ./cedet/ede ./cedet/semantic ./cedet/semantic/analyze ./cedet/semantic/bovine ./cedet/semantic/decorate ./cedet/semantic/symref ./cedet/semantic/wisent ./cedet/srecode ./emacs-lisp ./emacs-parallel ./emulation ./erc ./eshell ./gnus ./international ./language ./leim ./leim/ja-dic ./leim/quail ./mail ./mh-e ./net ./nxml ./org ./play ./progmodes ./textmodes ./url ./vc
>   GEN      loaddefs.el
> Making generated-autoload-file local to  *autoload-file* while let-bound!
> *** Error in `../src/bootstrap-emacs': realloc(): invalid next size: 0x00000000046edaf0 ***
> Fatal error 6: Aborted

Could be the same issue discussed here:

  http://lists.gnu.org/archive/html/emacs-devel/2015-11/msg01610.html

Does the previous loaddefs.el, the one that was NOT replaced due to
this, have any strange text in it, like null bytes?

bug#21982: 25.1.50; Building emacs-25 branch fails

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> >   GEN      loaddefs.el
> > Making generated-autoload-file local to *autoload-file* while
> > let-bound!
> > *** Error in `../src/bootstrap-emacs': realloc(): invalid next size:
> > 0x00000000046edaf0 ***
> > Fatal error 6: Aborted
>
> Could be the same issue discussed here:
>
>   http://lists.gnu.org/archive/html/emacs-devel/2015-11/msg01610.html

Sounds like that, yes.

> Does the previous loaddefs.el, the one that was NOT replaced due to
> this, have any strange text in it, like null bytes?

I found none.


Would it make sense to try to bisect the first occurrence of that
issue?  Then I will try to do that.


Michael.

bug#21982: 25.1.50; Building emacs-25 branch fails

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: 21982@debbugs.gnu.org
> Date: Mon, 23 Nov 2015 11:36:01 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > >   GEN      loaddefs.el
> > > Making generated-autoload-file local to *autoload-file* while
> > > let-bound!
> > > *** Error in `../src/bootstrap-emacs': realloc(): invalid next size:
> > > 0x00000000046edaf0 ***
> > > Fatal error 6: Aborted
> >
> > Could be the same issue discussed here:
> >
> >   http://lists.gnu.org/archive/html/emacs-devel/2015-11/msg01610.html
> 
> Sounds like that, yes.
> 
> > Does the previous loaddefs.el, the one that was NOT replaced due to
> > this, have any strange text in it, like null bytes?
> 
> I found none.
> 
> 
> Would it make sense to try to bisect the first occurrence of that
> issue?  Then I will try to do that.

If the abort is reproducible, by all means please do, and thanks.

bug#21982: 25.1.50; Building emacs-25 branch fails

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> If the abort is reproducible, by all means please do, and thanks.

git bisect says that:

--8<---------------cut here---------------start------------->8---
c210b8b128c17929dbb8e0b0564ee25930d44dd1 is the first bad commit
commit c210b8b128c17929dbb8e0b0564ee25930d44dd1
Author: Juanma Barranquero <lekktu@gmail.com>
Date:   Thu Nov 19 21:32:43 2015 +0100
    Discover repository version in linked worktrees (bug#21930)
    
    * lisp/version.el (emacs-repository--version-git-1): Do not assume
    HEAD is at .git/HEAD, it can also be at .git/worktrees/<branch>/HEAD.
    (emacs-repository-get-version): Grok linked worktrees when EXTERNAL
    is nil too.
--8<---------------cut here---------------end--------------->8---

I verified that it is indeed bad and that the parent commit is good,
whereby "good" means it builds successfully and "bad" means building
fails.

Does that help?


Regards,

Michael.

bug#21982: 25.1.50; Building emacs-25 branch fails

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: 21982@debbugs.gnu.org
> Date: Mon, 23 Nov 2015 21:35:50 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > If the abort is reproducible, by all means please do, and thanks.
> 
> git bisect says that:
> 
> --8<---------------cut here---------------start------------->8---
> c210b8b128c17929dbb8e0b0564ee25930d44dd1 is the first bad commit
> commit c210b8b128c17929dbb8e0b0564ee25930d44dd1
> Author: Juanma Barranquero <lekktu@gmail.com>
> Date:   Thu Nov 19 21:32:43 2015 +0100
>     Discover repository version in linked worktrees (bug#21930)
>     
>     * lisp/version.el (emacs-repository--version-git-1): Do not assume
>     HEAD is at .git/HEAD, it can also be at .git/worktrees/<branch>/HEAD.
>     (emacs-repository-get-version): Grok linked worktrees when EXTERNAL
>     is nil too.
> --8<---------------cut here---------------end--------------->8---
> 
> I verified that it is indeed bad and that the parent commit is good,
> whereby "good" means it builds successfully and "bad" means building
> fails.
> 
> Does that help?

Well, sort of.  Granted, no Lisp change can ever cause thrashing of
the malloc arena, so the above could only expose a bug that was
already there.

Was your branch tree created by "git worktree"?

bug#21982: 25.1.50; Building emacs-25 branch fails

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> Was your branch tree created by "git worktree"?

I never used that command, so I guess "no".


Michael.

bug#21982: 25.1.50; Building emacs-25 branch fails

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: 21982@debbugs.gnu.org
> Date: Mon, 23 Nov 2015 21:54:45 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Was your branch tree created by "git worktree"?
> 
> I never used that command, so I guess "no".

Can you run Emacs under valgrind?  It should be able to find the
offending code.  (I assume that just running by hand the single
command that aborts is sufficient to reproduce the problem.)

Btw, the problem with "End of file during parsing" I reported came
back today: I again got null bytes in the middle of the file.  So
whatever was causing corruption of loaddefs.el is still with us.

Thanks.

bug#21982: 25.1.50; Building emacs-25 branch fails

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> Can you run Emacs under valgrind?  It should be able to find the
> offending code.  (I assume that just running by hand the single
> command that aborts is sufficient to reproduce the problem.)

I would first have to learn how to do that.

I did something different in the meantime.  I bisected again, but with
version.el fix from the first bad commit.  This leaded to

--8<---------------cut here---------------start------------->8---
a4c6f55b9a222849a1c5d590589b1f8f0627d6f8 is the first bad commit
commit a4c6f55b9a222849a1c5d590589b1f8f0627d6f8
Author: Dmitry Gutov <dgutov@yandex.ru>
Date:   Sun Nov 15 07:00:45 2015 +0200
    Unify the absolutely equal xref-backend-references implementations
    
    * lisp/progmodes/elisp-mode.el (xref-backend-references):
    Remove.
    
    * lisp/progmodes/etags.el (xref-backend-references):
    Remove.
    
    * lisp/progmodes/xref.el (xref-backend-references):
    Define the default implementation.
--8<---------------cut here---------------end--------------->8---

So, this is the commit that caused the change in version.el to break
Emacs.  Dunno if this is the end of the chain.

Is this information useful?


Michael.

bug#21982: 25.1.50; Building emacs-25 branch fails

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: 21982@debbugs.gnu.org
> Date: Tue, 24 Nov 2015 18:48:09 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Can you run Emacs under valgrind?  It should be able to find the
> > offending code.  (I assume that just running by hand the single
> > command that aborts is sufficient to reproduce the problem.)
> 
> I would first have to learn how to do that.

Perhaps Paul could help you.

> I did something different in the meantime.  I bisected again, but with
> version.el fix from the first bad commit.  This leaded to
> 
> --8<---------------cut here---------------start------------->8---
> a4c6f55b9a222849a1c5d590589b1f8f0627d6f8 is the first bad commit
> commit a4c6f55b9a222849a1c5d590589b1f8f0627d6f8
> Author: Dmitry Gutov <dgutov@yandex.ru>
> Date:   Sun Nov 15 07:00:45 2015 +0200
>     Unify the absolutely equal xref-backend-references implementations
>     
>     * lisp/progmodes/elisp-mode.el (xref-backend-references):
>     Remove.
>     
>     * lisp/progmodes/etags.el (xref-backend-references):
>     Remove.
>     
>     * lisp/progmodes/xref.el (xref-backend-references):
>     Define the default implementation.
> --8<---------------cut here---------------end--------------->8---
> 
> So, this is the commit that caused the change in version.el to break
> Emacs.  Dunno if this is the end of the chain.
> 
> Is this information useful?

I don't see how this could be relevant.  In particular, this commit
doesn't touch version.el.  How could it cause a change in version.el?
What am I missing?

bug#21982: 25.1.50; Building emacs-25 branch fails

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> I don't see how this could be relevant.  In particular, this commit
> doesn't touch version.el.  How could it cause a change in version.el?
> What am I missing?

Good question.  I tried to recompile with some changes related to these
commits to find an answer.  Compiling never failed.  And now, even
compiling the emacs-25 branch doesn't fail.  AFAICT, the repository is
in the same state as yesterday, with the same head commit.
Yesterday, it failed to compile, now it doesn't.


Michael.

bug#21982: 25.1.50; Building emacs-25 branch fails

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: 21982@debbugs.gnu.org
> Date: Wed, 25 Nov 2015 18:58:58 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I don't see how this could be relevant.  In particular, this commit
> > doesn't touch version.el.  How could it cause a change in version.el?
> > What am I missing?
> 
> Good question.  I tried to recompile with some changes related to these
> commits to find an answer.  Compiling never failed.  And now, even
> compiling the emacs-25 branch doesn't fail.  AFAICT, the repository is
> in the same state as yesterday, with the same head commit.
> Yesterday, it failed to compile, now it doesn't.

Heisenbugs, sigh...

bug#21982: 25.1.50; Building emacs-25 branch fails

[npostavs]

tags 21982 unreproducible
close 21982
quit

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> I don't see how this could be relevant.  In particular, this commit
>> doesn't touch version.el.  How could it cause a change in version.el?
>> What am I missing?
>
> Good question.  I tried to recompile with some changes related to these
> commits to find an answer.  Compiling never failed.  And now, even
> compiling the emacs-25 branch doesn't fail.  AFAICT, the repository is
> in the same state as yesterday, with the same head commit.
> Yesterday, it failed to compile, now it doesn't.

I guess it's okay to close this now.