GNU bug report logs - #21982
25.1.50; Building emacs-25 branch fails

Previous Next

Package: emacs;

Reported by: Michael Heerdegen <michael_heerdegen <at> web.de>

Date: Sun, 22 Nov 2015 17:59:02 UTC

Severity: normal

Tags: unreproducible

Found in version 25.1.50

Done: npostavs <at> users.sourceforge.net

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 21982 in the body.
You can then email your comments to 21982 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#21982; Package emacs. (Sun, 22 Nov 2015 17:59:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Heerdegen <michael_heerdegen <at> web.de>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sun, 22 Nov 2015 17:59:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.1.50; Building emacs-25 branch fails
Date: Sun, 22 Nov 2015 18:58:30 +0100
[Message part 1 (text/plain, inline)]
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:

[output.txt (text/plain, inline)]
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
[Message part 3 (text/plain, inline)]
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


Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#21982; Package emacs. (Sun, 22 Nov 2015 18:46:03 GMT) Full text and rfc822 format available.

Message #8 received at 21982 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 21982 <at> debbugs.gnu.org
Subject: Re: bug#21982: 25.1.50; Building emacs-25 branch fails
Date: Sun, 22 Nov 2015 20:45:01 +0200
> From: Michael Heerdegen <michael_heerdegen <at> 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?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#21982; Package emacs. (Mon, 23 Nov 2015 10:37:02 GMT) Full text and rfc822 format available.

Message #11 received at 21982 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 21982 <at> debbugs.gnu.org
Subject: Re: bug#21982: 25.1.50; Building emacs-25 branch fails
Date: Mon, 23 Nov 2015 11:36:01 +0100
Eli Zaretskii <eliz <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#21982; Package emacs. (Mon, 23 Nov 2015 16:20:02 GMT) Full text and rfc822 format available.

Message #14 received at 21982 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 21982 <at> debbugs.gnu.org
Subject: Re: bug#21982: 25.1.50; Building emacs-25 branch fails
Date: Mon, 23 Nov 2015 18:19:12 +0200
> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Cc: 21982 <at> debbugs.gnu.org
> Date: Mon, 23 Nov 2015 11:36:01 +0100
> 
> Eli Zaretskii <eliz <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#21982; Package emacs. (Mon, 23 Nov 2015 20:36:02 GMT) Full text and rfc822 format available.

Message #17 received at 21982 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 21982 <at> debbugs.gnu.org
Subject: Re: bug#21982: 25.1.50; Building emacs-25 branch fails
Date: Mon, 23 Nov 2015 21:35:50 +0100
Eli Zaretskii <eliz <at> 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 <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#21982; Package emacs. (Mon, 23 Nov 2015 20:50:02 GMT) Full text and rfc822 format available.

Message #20 received at 21982 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 21982 <at> debbugs.gnu.org
Subject: Re: bug#21982: 25.1.50; Building emacs-25 branch fails
Date: Mon, 23 Nov 2015 22:49:24 +0200
> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Cc: 21982 <at> debbugs.gnu.org
> Date: Mon, 23 Nov 2015 21:35:50 +0100
> 
> Eli Zaretskii <eliz <at> 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 <at> 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"?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#21982; Package emacs. (Mon, 23 Nov 2015 20:55:02 GMT) Full text and rfc822 format available.

Message #23 received at 21982 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 21982 <at> debbugs.gnu.org
Subject: Re: bug#21982: 25.1.50; Building emacs-25 branch fails
Date: Mon, 23 Nov 2015 21:54:45 +0100
Eli Zaretskii <eliz <at> gnu.org> writes:

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

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


Michael.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#21982; Package emacs. (Tue, 24 Nov 2015 16:16:01 GMT) Full text and rfc822 format available.

Message #26 received at 21982 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 21982 <at> debbugs.gnu.org
Subject: Re: bug#21982: 25.1.50; Building emacs-25 branch fails
Date: Tue, 24 Nov 2015 18:15:40 +0200
> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Cc: 21982 <at> debbugs.gnu.org
> Date: Mon, 23 Nov 2015 21:54:45 +0100
> 
> Eli Zaretskii <eliz <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#21982; Package emacs. (Tue, 24 Nov 2015 17:49:02 GMT) Full text and rfc822 format available.

Message #29 received at 21982 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 21982 <at> debbugs.gnu.org
Subject: Re: bug#21982: 25.1.50; Building emacs-25 branch fails
Date: Tue, 24 Nov 2015 18:48:09 +0100
Eli Zaretskii <eliz <at> 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 <at> 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.





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#21982; Package emacs. (Tue, 24 Nov 2015 17:58:01 GMT) Full text and rfc822 format available.

Message #32 received at 21982 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 21982 <at> debbugs.gnu.org
Subject: Re: bug#21982: 25.1.50; Building emacs-25 branch fails
Date: Tue, 24 Nov 2015 19:57:32 +0200
> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Cc: 21982 <at> debbugs.gnu.org
> Date: Tue, 24 Nov 2015 18:48:09 +0100
> 
> Eli Zaretskii <eliz <at> 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 <at> 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?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#21982; Package emacs. (Wed, 25 Nov 2015 18:00:05 GMT) Full text and rfc822 format available.

Message #35 received at 21982 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 21982 <at> debbugs.gnu.org
Subject: Re: bug#21982: 25.1.50; Building emacs-25 branch fails
Date: Wed, 25 Nov 2015 18:58:58 +0100
Eli Zaretskii <eliz <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#21982; Package emacs. (Wed, 25 Nov 2015 18:22:02 GMT) Full text and rfc822 format available.

Message #38 received at 21982 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 21982 <at> debbugs.gnu.org
Subject: Re: bug#21982: 25.1.50; Building emacs-25 branch fails
Date: Wed, 25 Nov 2015 20:20:58 +0200
> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Cc: 21982 <at> debbugs.gnu.org
> Date: Wed, 25 Nov 2015 18:58:58 +0100
> 
> Eli Zaretskii <eliz <at> 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...




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#21982; Package emacs. (Sun, 29 Jan 2017 23:22:02 GMT) Full text and rfc822 format available.

Message #41 received at 21982 <at> debbugs.gnu.org (full text, mbox):

From: npostavs <at> users.sourceforge.net
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 21982 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#21982: 25.1.50; Building emacs-25 branch fails
Date: Sun, 29 Jan 2017 18:22:16 -0500
tags 21982 unreproducible
close 21982
quit

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> Eli Zaretskii <eliz <at> 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.




Added tag(s) unreproducible. Request was from npostavs <at> users.sourceforge.net to control <at> debbugs.gnu.org. (Sun, 29 Jan 2017 23:22:02 GMT) Full text and rfc822 format available.

bug closed, send any further explanations to 21982 <at> debbugs.gnu.org and Michael Heerdegen <michael_heerdegen <at> web.de> Request was from npostavs <at> users.sourceforge.net to control <at> debbugs.gnu.org. (Sun, 29 Jan 2017 23:22:03 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Mon, 27 Feb 2017 12:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 8 years and 117 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.