* bug#21982: 25.1.50; Building emacs-25 branch fails
@ 2015-11-22 17:58 Michael Heerdegen
2015-11-22 18:45 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Michael Heerdegen @ 2015-11-22 17:58 UTC (permalink / raw
To: 21982
[-- 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#21982: 25.1.50; Building emacs-25 branch fails
2015-11-22 17:58 bug#21982: 25.1.50; Building emacs-25 branch fails Michael Heerdegen
@ 2015-11-22 18:45 ` Eli Zaretskii
2015-11-23 10:36 ` Michael Heerdegen
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2015-11-22 18:45 UTC (permalink / raw
To: Michael Heerdegen; +Cc: 21982
> 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?
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#21982: 25.1.50; Building emacs-25 branch fails
2015-11-22 18:45 ` Eli Zaretskii
@ 2015-11-23 10:36 ` Michael Heerdegen
2015-11-23 16:19 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Michael Heerdegen @ 2015-11-23 10:36 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 21982
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#21982: 25.1.50; Building emacs-25 branch fails
2015-11-23 10:36 ` Michael Heerdegen
@ 2015-11-23 16:19 ` Eli Zaretskii
2015-11-23 20:35 ` Michael Heerdegen
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2015-11-23 16:19 UTC (permalink / raw
To: Michael Heerdegen; +Cc: 21982
> 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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#21982: 25.1.50; Building emacs-25 branch fails
2015-11-23 16:19 ` Eli Zaretskii
@ 2015-11-23 20:35 ` Michael Heerdegen
2015-11-23 20:49 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Michael Heerdegen @ 2015-11-23 20:35 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 21982
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#21982: 25.1.50; Building emacs-25 branch fails
2015-11-23 20:35 ` Michael Heerdegen
@ 2015-11-23 20:49 ` Eli Zaretskii
2015-11-23 20:54 ` Michael Heerdegen
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2015-11-23 20:49 UTC (permalink / raw
To: Michael Heerdegen; +Cc: 21982
> 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"?
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#21982: 25.1.50; Building emacs-25 branch fails
2015-11-23 20:49 ` Eli Zaretskii
@ 2015-11-23 20:54 ` Michael Heerdegen
2015-11-24 16:15 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Michael Heerdegen @ 2015-11-23 20:54 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 21982
Eli Zaretskii <eliz@gnu.org> writes:
> Was your branch tree created by "git worktree"?
I never used that command, so I guess "no".
Michael.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#21982: 25.1.50; Building emacs-25 branch fails
2015-11-23 20:54 ` Michael Heerdegen
@ 2015-11-24 16:15 ` Eli Zaretskii
2015-11-24 17:48 ` Michael Heerdegen
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2015-11-24 16:15 UTC (permalink / raw
To: Michael Heerdegen; +Cc: 21982
> 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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#21982: 25.1.50; Building emacs-25 branch fails
2015-11-24 16:15 ` Eli Zaretskii
@ 2015-11-24 17:48 ` Michael Heerdegen
2015-11-24 17:57 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Michael Heerdegen @ 2015-11-24 17:48 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 21982
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#21982: 25.1.50; Building emacs-25 branch fails
2015-11-24 17:48 ` Michael Heerdegen
@ 2015-11-24 17:57 ` Eli Zaretskii
2015-11-25 17:58 ` Michael Heerdegen
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2015-11-24 17:57 UTC (permalink / raw
To: Michael Heerdegen; +Cc: 21982
> 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?
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#21982: 25.1.50; Building emacs-25 branch fails
2015-11-24 17:57 ` Eli Zaretskii
@ 2015-11-25 17:58 ` Michael Heerdegen
2015-11-25 18:20 ` Eli Zaretskii
2017-01-29 23:22 ` npostavs
0 siblings, 2 replies; 13+ messages in thread
From: Michael Heerdegen @ 2015-11-25 17:58 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 21982
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#21982: 25.1.50; Building emacs-25 branch fails
2015-11-25 17:58 ` Michael Heerdegen
@ 2015-11-25 18:20 ` Eli Zaretskii
2017-01-29 23:22 ` npostavs
1 sibling, 0 replies; 13+ messages in thread
From: Eli Zaretskii @ 2015-11-25 18:20 UTC (permalink / raw
To: Michael Heerdegen; +Cc: 21982
> 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...
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#21982: 25.1.50; Building emacs-25 branch fails
2015-11-25 17:58 ` Michael Heerdegen
2015-11-25 18:20 ` Eli Zaretskii
@ 2017-01-29 23:22 ` npostavs
1 sibling, 0 replies; 13+ messages in thread
From: npostavs @ 2017-01-29 23:22 UTC (permalink / raw
To: Michael Heerdegen; +Cc: 21982
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2017-01-29 23:22 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-11-22 17:58 bug#21982: 25.1.50; Building emacs-25 branch fails Michael Heerdegen
2015-11-22 18:45 ` Eli Zaretskii
2015-11-23 10:36 ` Michael Heerdegen
2015-11-23 16:19 ` Eli Zaretskii
2015-11-23 20:35 ` Michael Heerdegen
2015-11-23 20:49 ` Eli Zaretskii
2015-11-23 20:54 ` Michael Heerdegen
2015-11-24 16:15 ` Eli Zaretskii
2015-11-24 17:48 ` Michael Heerdegen
2015-11-24 17:57 ` Eli Zaretskii
2015-11-25 17:58 ` Michael Heerdegen
2015-11-25 18:20 ` Eli Zaretskii
2017-01-29 23:22 ` npostavs
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.