compilation failure

compilation failure

[Werner LEMBERG]

[bzr rev 103778]

The last two days, `make boostrap' aborts on my GNU/Linux box with

  Loading loadup.el (source)...
  Using load-path (/home/wl/bzr/emacs.compiled/lisp)
  Loading emacs-lisp/byte-run...
  Loading emacs-lisp/backquote...
  Loading subr...
  Loading version.el (source)...
  Loading widget...
  /bin/sh: Zeile 8: 29927 Speicherzugriffsfehler  LC_ALL=C `/bin/pwd`/temacs -batch -l loadup dump
  make[2]: *** [emacs] Fehler 1
  make[2]: Leaving directory `/usr/local/home/wl/bzr/emacs.compiled/src'
  make[1]: *** [src] Fehler 2
  make[1]: Leaving directory `/usr/local/home/wl/bzr/emacs.compiled'
  make: *** [bootstrap] Fehler 2

Are there some bigger changes under construction so that this expected
currently?


    Werner

Re: compilation failure

[Paul Eggert]

On 03/29/2011 11:13 PM, Werner LEMBERG wrote:

> [bzr rev 103778]
> The last two days, `make boostrap' aborts on my GNU/Linux box ...
> Are there some bigger changes under construction so that this expected
> currently?

No, it should be working.  I'm not observing problems with bzr 103778,
either with RHEL 5.6 x86-64 (with self-built GCC 4.6.0), or with
Ubuntu 10.10 x86 (with system-supplied GCC).

Re: compilation failure

[Werner LEMBERG]

>> The last two days, `make boostrap' aborts on my GNU/Linux box ...
>> Are there some bigger changes under construction so that this expected
>> currently?
>
> No, it should be working.  I'm not observing problems with bzr 103778,
> either with RHEL 5.6 x86-64 (with self-built GCC 4.6.0), or with
> Ubuntu 10.10 x86 (with system-supplied GCC).

Strange.  I'm using openSuSE Factory.  Interestingly, if I simply
manually say

  ./temacs -batch -l loadup dump

within my de_DE.UTF-8 locale, it succeeds, but using the command from
the Makefile,

  LC_ALL=C ./temacs -batch -l loadup dump

it aborts.  Calling gdb, I get the backtrace shown below.  Note that
I'm doing a normal build without any additional options.


    Werner


======================================================================

#0  mark_object (arg=138477574) at alloc.c:5429
#1  0x08195d4e in mark_maybe_pointer (p=<optimized out>) at alloc.c:4083
#2  mark_memory (offset=0, end=0xbfffed98, start=0x841313a) at alloc.c:4133
#3  mark_stack () at alloc.c:4381
#4  Fgarbage_collect () at alloc.c:4966
#5  0x081aa12d in Feval (form=138874790) at eval.c:2248
#6  0x081aa3dd in Fprogn (args=<optimized out>) at eval.c:343
#7  0x081aa66d in funcall_lambda (fun=138874846, nargs=1, arg_vector=0xbfffe268) at eval.c:3051
#8  0x081aa8a3 in Ffuncall (nargs=2, args=0xbfffe264) at eval.c:2930
#9  0x081ab048 in funcall_nil (nargs=2, args=0xbfffe264) at eval.c:2419
#10 0x081a950f in run_hook_with_args (nargs=2, args=0xbfffe264, funcall=0x81ab030 <funcall_nil>)
    at eval.c:2608
#11 0x081a96d0 in Frun_hook_with_args (nargs=2, args=0xbfffe264) at eval.c:2469
#12 0x081aab02 in Ffuncall (nargs=3, args=0xbfffe260) at eval.c:2852
#13 0x081e1736 in Fbyte_code (bytestr=<optimized out>, vector=136581181, maxdepth=24) at bytecode.c:691
#14 0x081aa568 in funcall_lambda (fun=136581125, nargs=1, arg_vector=0xbfffe3ec) at eval.c:3058
#15 0x081aa8a3 in Ffuncall (nargs=2, args=0xbfffe3e8) at eval.c:2930
#16 0x081aaf95 in call1 (fn=138604082, arg1=138921753) at eval.c:2671
#17 0x081cda6d in Fload (file=138921849, noerror=138490170, nomessage=138490170, nosuffix=138490170, 
    must_suffix=138490170) at lread.c:1175
#18 0x081aa0ad in Feval (form=138476214) at eval.c:2265
#19 0x081ccf81 in readevalloop (readcharfun=138603090, stream=0x8446a10, sourcename=138613193, printflag=0, 
    unibyte=138490170, readfun=138490170, start=138490170, end=138490170, evalfun=<optimized out>)
    at lread.c:1675
#20 0x081cda2a in Fload (file=138613065, noerror=138490170, nomessage=138490170, nosuffix=138490170, 
    must_suffix=138490170) at lread.c:1161
#21 0x081aa0ad in Feval (form=138469934) at eval.c:2265
#22 0x0813e343 in top_level_2 () at keyboard.c:1137
#23 0x081a9011 in internal_condition_case (bfun=0x813e330 <top_level_2>, handlers=138521714, hfun=
    0x813f2a0 <cmd_error>) at eval.c:1407
#24 0x0813eb45 in top_level_1 (ignore=138490170) at keyboard.c:1145
#25 0x081a8f41 in internal_catch (tag=138519730, func=0x813eae0 <top_level_1>, arg=138490170) at eval.c:1154
---Type <return> to continue, or q <return> to quit---
#26 0x0813f453 in command_loop () at keyboard.c:1100
#27 0x0813f51b in recursive_edit_1 () at keyboard.c:730
#28 0x0813f642 in Frecursive_edit () at keyboard.c:792
#29 0x0813b4ac in main (argc=<optimized out>, argv=0xbfffee64) at emacs.c:1685

Lisp Backtrace:
"garbage-collect" (0xbfffe004)
0x8470fd8 Lisp type 6
"run-hook-with-args" (0xbfffe264)
"do-after-load-evaluation" (0xbfffe3ec)
"load" (0xbfffe574)
"load" (0xbfffe7b4)

Re: compilation failure

[Jim Meyering]

Werner LEMBERG wrote:
>>> The last two days, `make boostrap' aborts on my GNU/Linux box ...
>>> Are there some bigger changes under construction so that this expected
>>> currently?
>>
>> No, it should be working.  I'm not observing problems with bzr 103778,
>> either with RHEL 5.6 x86-64 (with self-built GCC 4.6.0), or with
>> Ubuntu 10.10 x86 (with system-supplied GCC).
>
> Strange.  I'm using openSuSE Factory.  Interestingly, if I simply
> manually say
>
>   ./temacs -batch -l loadup dump
>
> within my de_DE.UTF-8 locale, it succeeds, but using the command from
> the Makefile,
>
>   LC_ALL=C ./temacs -batch -l loadup dump
>
> it aborts.  Calling gdb, I get the backtrace shown below.  Note that
> I'm doing a normal build without any additional options.

Have you tried building with LC_ALL=C in your environment?

This command,
  env MALLOC_PERTURB_=0 MALLOC_CHECK_=0 make -j9 bootstrap
has succeeded for me on each of the last three mornings (Mar 28-30).

I manually set those two MALLOC_*_ variables to 0 because
when I don't, emacs fails to bootstrap.

When I set them like this (as I normally do),

    $ env|grep MALL                                                              :
    MALLOC_PERTURB_=39
    MALLOC_CHECK_=3

The build fails like this on F15:

    Compiling quail/CCDOSPY.el
    Compiling quail/Punct.el
    Compiling quail/QJ.el
    Compiling quail/SW.el
    Compiling quail/TONEPY.el
    Compiling quail/PY.el
    Compiling quail/CTLau.el
    Compiling quail/CTLau-b5.el
    >>Error occurred processing quail/CCDOSPY.el: File error (("Opening input file" "
    No such file or directory" "/tmp/.x/emacs/leim/quail/CCDOSPY.el"))
    >>Error occurred processing quail/QJ.el: File error (("Opening input file" "No su
    ch file or directory" "/tmp/.x/emacs/leim/quail/QJ.el"))
    make[1]: *** [quail/CCDOSPY.elc] Error 1
    make[1]: *** Waiting for unfinished jobs....
    make[1]: *** [quail/QJ.elc] Error 1
    make[1]: Entering directory `/tmp/.x/emacs/lisp'
    >>Error occurred processing quail/Punct.el: File error (("Opening input file" "No
     such file or directory" "/tmp/.x/emacs/leim/quail/Punct.el"))
    make[1]: *** [quail/Punct.elc] Error 1
    >>Error occurred processing quail/SW.el: File error (("Opening input file" "No su
    ch file or directory" "/tmp/.x/emacs/leim/quail/SW.el"))
    make[1]: *** [quail/SW.elc] Error 1
    >>Error occurred processing quail/TONEPY.el: File error (("Opening input file" "N
    o such file or directory" "/tmp/.x/emacs/leim/quail/TONEPY.el"))
    make[1]: *** [quail/TONEPY.elc] Error 1

    In toplevel form:
    quail/CTLau.el:52:1:Error: Memory exhausted--use C-x s then exit and restart Emac
    s
    make[1]: *** [quail/CTLau.elc] Error 1

    In toplevel form:
    quail/PY.el:88:1:Error: Memory exhausted--use C-x s then exit and restart Emacs
    make[1]: *** [quail/PY.elc] Error 1

    In toplevel form:
    quail/CTLau-b5.el:52:1:Error: Memory exhausted--use C-x s then exit and restart Emacs
    make[1]: *** [quail/CTLau-b5.elc] Error 1
    make[1]: Leaving directory `/tmp/.x/emacs/leim'
    make: *** [leim] Error 2
    make: *** Waiting for unfinished jobs....
    make[2]: Entering directory `/tmp/.x/emacs/lisp'
    make[2]: Nothing to be done for `compile-targets'.
    make[2]: Leaving directory `/tmp/.x/emacs/lisp'
    make[1]: Leaving directory `/tmp/.x/emacs/lisp'
    [Exit 2]


At this point, resetting those two envvars has no effect,
presumably because the damage was done in creating a broken
temacs.  Here, we're just running the broken tool.

What does this mean?
I suspect that emacs is using free'd memory containing
values that would normally be unoffensive, but when you set
those envvars (esp MALLOC_PERTURB_) to nonzero, it makes
glibc scribble on free'd buffers, and that makes emacs
exhibit an actual failure.

Re: compilation failure

[Werner LEMBERG]

> Have you tried building with LC_ALL=C in your environment?

I've just tried

  LC_ALL=C make bootstrap

and it fails similarly:

  Loading emacs-lisp/byte-run (source)...
  Loading emacs-lisp/backquote (source)...
  Loading subr (source)...
  Loading version.el (source)...
  Loading widget (source)...
  Loading custom (source)...
  Loading emacs-lisp/map-ynp (source)...
  Loading cus-start (source)...
  Loading international/mule (source)...
  Loading international/mule-conf (source)...
  /bin/sh: line 5:  6348 Segmentation fault
                      `/bin/pwd`/temacs --batch --load loadup bootstrap



    Werner

Re: compilation failure

[Eli Zaretskii]

> Date: Wed, 30 Mar 2011 08:52:38 +0200 (CEST)
> From: Werner LEMBERG <wl@gnu.org>
> Cc: emacs-devel@gnu.org
> 
>   LC_ALL=C ./temacs -batch -l loadup dump
> 
> it aborts.  Calling gdb, I get the backtrace shown below.  Note that
> I'm doing a normal build without any additional options.
> 
> 
>     Werner
> 
> 
> ======================================================================
> 
> #0  mark_object (arg=138477574) at alloc.c:5429
> #1  0x08195d4e in mark_maybe_pointer (p=<optimized out>) at alloc.c:4083
> #2  mark_memory (offset=0, end=0xbfffed98, start=0x841313a) at alloc.c:4133
> #3  mark_stack () at alloc.c:4381
> #4  Fgarbage_collect () at alloc.c:4966

Can you try unoptimized build (with "-O0 -ggdb -g3")?  If that crashes
as well, please show the backtrace from an unoptimized build, because
backtraces from optimized builds cannot be trusted.

Based on first glance, it crashes in GC, which means memory corruption
somewhere.  There are instructions in etc/DEBUG about how to debug
crashes in GC, so if you can follow them, please do; since this crash
is not very deep under Fgarbage_collect, I presume you will find out
the bad data structure fairly easy.

Failing that, please leave the crashed Emacs under GDB, so that we
could ask you to show important values.

If an unoptimized build does not crash, then the plot will thicken...

Btw, what version of GCC do you have on Ubuntu 10.10?

Re: compilation failure

[Eli Zaretskii]

> From: Jim Meyering <jim@meyering.net>
> Date: Wed, 30 Mar 2011 09:42:42 +0200
> Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org
> 
> This command,
>   env MALLOC_PERTURB_=0 MALLOC_CHECK_=0 make -j9 bootstrap
> has succeeded for me on each of the last three mornings (Mar 28-30).
> 
> I manually set those two MALLOC_*_ variables to 0 because
> when I don't, emacs fails to bootstrap.

It's a pity this problem was not reported to the bug tracker.  (At
least I couldn't find it; apologies if I missed it.)

> I suspect that emacs is using free'd memory containing
> values that would normally be unoffensive, but when you set
> those envvars (esp MALLOC_PERTURB_) to nonzero, it makes
> glibc scribble on free'd buffers, and that makes emacs
> exhibit an actual failure.

Can you use bisect to find the guilty commit?

Re: compilation failure

[Eli Zaretskii]

> Date: Wed, 30 Mar 2011 10:04:57 +0200 (CEST)
> From: Werner LEMBERG <wl@gnu.org>
> Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org
> 
>   /bin/sh: line 5:  6348 Segmentation fault
>                       `/bin/pwd`/temacs --batch --load loadup bootstrap

Can you show a backtrace from this one, please?

Re: compilation failure

[Werner LEMBERG]

From: Eli Zaretskii <eliz@gnu.org>
Subject: Re: compilation failure
Date: Wed, 30 Mar 2011 07:37:44 -0400

>> Date: Wed, 30 Mar 2011 10:04:57 +0200 (CEST)
>> From: Werner LEMBERG <wl@gnu.org>
>> Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org
>> 
>>   /bin/sh: line 5:  6348 Segmentation fault
>>                       `/bin/pwd`/temacs --batch --load loadup bootstrap
> 
> Can you show a backtrace from this one, please?

Here it is.


    Werner


======================================================================


#0  mark_object (arg=138477574) at alloc.c:5429
#1  0x08195d4e in mark_maybe_pointer (p=<optimized out>) at alloc.c:4083
#2  mark_memory (offset=0, end=0xbfffed98, start=0x841313a) at alloc.c:4133
#3  mark_stack () at alloc.c:4381
#4  Fgarbage_collect () at alloc.c:4966
#5  0x081a9c69 in Feval (form=138925598) at eval.c:2142
#6  0x081a9f3f in Feval (form=136569574) at eval.c:2312
#7  0x081aa3dd in Fprogn (args=<optimized out>) at eval.c:343
#8  0x081aa66d in funcall_lambda (fun=136572718, nargs=2, arg_vector=0xbfffce50) at eval.c:3051
#9  0x081a9b0e in apply_lambda (fun=136572718, args=<optimized out>, eval_flag=1) at eval.c:2982
#10 0x081a9db5 in Feval (form=136571550) at eval.c:2314
#11 0x081aa290 in Fsetq (args=136571542) at eval.c:442
#12 0x081aa17f in Feval (form=136571534) at eval.c:2198
#13 0x081aa3dd in Fprogn (args=<optimized out>) at eval.c:343
#14 0x081aca80 in Fwhile (args=136571526) at eval.c:1024
#15 0x081aa17f in Feval (form=136571358) at eval.c:2198
#16 0x081aa3dd in Fprogn (args=<optimized out>) at eval.c:343
#17 0x081acf21 in Flet (args=136571350) at eval.c:1002
#18 0x081aa17f in Feval (form=136571214) at eval.c:2198
#19 0x081aa3dd in Fprogn (args=<optimized out>) at eval.c:343
#20 0x081aa17f in Feval (form=136569630) at eval.c:2198
#21 0x081aa3dd in Fprogn (args=<optimized out>) at eval.c:343
#22 0x081aa66d in funcall_lambda (fun=136572718, nargs=2, arg_vector=0xbfffd360) at eval.c:3051
#23 0x081a9b0e in apply_lambda (fun=136572718, args=<optimized out>, eval_flag=1) at eval.c:2982
#24 0x081a9db5 in Feval (form=136571550) at eval.c:2314
#25 0x081aa290 in Fsetq (args=136571542) at eval.c:442
#26 0x081aa17f in Feval (form=136571534) at eval.c:2198
#27 0x081aa3dd in Fprogn (args=<optimized out>) at eval.c:343
#28 0x081aca80 in Fwhile (args=136571526) at eval.c:1024
#29 0x081aa17f in Feval (form=136571358) at eval.c:2198
#30 0x081aa3dd in Fprogn (args=<optimized out>) at eval.c:343
#31 0x081acf21 in Flet (args=136571350) at eval.c:1002
---Type <return> to continue, or q <return> to quit---
#32 0x081aa17f in Feval (form=136571214) at eval.c:2198
#33 0x081aa3dd in Fprogn (args=<optimized out>) at eval.c:343
#34 0x081aa17f in Feval (form=136569630) at eval.c:2198
#35 0x081aa3dd in Fprogn (args=<optimized out>) at eval.c:343
#36 0x081aa66d in funcall_lambda (fun=136572718, nargs=2, arg_vector=0xbfffd870) at eval.c:3051
#37 0x081a9b0e in apply_lambda (fun=136572718, args=<optimized out>, eval_flag=1) at eval.c:2982
#38 0x081a9db5 in Feval (form=136571550) at eval.c:2314
#39 0x081aa290 in Fsetq (args=136571542) at eval.c:442
#40 0x081aa17f in Feval (form=136571534) at eval.c:2198
#41 0x081aa3dd in Fprogn (args=<optimized out>) at eval.c:343
#42 0x081aca80 in Fwhile (args=136571526) at eval.c:1024
#43 0x081aa17f in Feval (form=136571358) at eval.c:2198
#44 0x081aa3dd in Fprogn (args=<optimized out>) at eval.c:343
#45 0x081acf21 in Flet (args=136571350) at eval.c:1002
#46 0x081aa17f in Feval (form=136571214) at eval.c:2198
#47 0x081aa3dd in Fprogn (args=<optimized out>) at eval.c:343
#48 0x081aa17f in Feval (form=136569630) at eval.c:2198
#49 0x081aa3dd in Fprogn (args=<optimized out>) at eval.c:343
#50 0x081aa66d in funcall_lambda (fun=136572718, nargs=1, arg_vector=0xbfffdd80) at eval.c:3051
#51 0x081a9b0e in apply_lambda (fun=136572718, args=<optimized out>, eval_flag=1) at eval.c:2982
#52 0x081a9db5 in Feval (form=136569030) at eval.c:2314
#53 0x081a9ee0 in Feval (form=136569014) at eval.c:2236
#54 0x081aa3dd in Fprogn (args=<optimized out>) at eval.c:343
#55 0x081aa66d in funcall_lambda (fun=136568958, nargs=1, arg_vector=0xbfffe08c) at eval.c:3051
#56 0x081aa8a3 in Ffuncall (nargs=2, args=0xbfffe088) at eval.c:2930
#57 0x081abbe7 in Fapply (nargs=2, args=0xbfffe088) at eval.c:2354
#58 0x081ab07d in apply1 (fn=136568958, arg=136564670) at eval.c:2645
#59 0x081a9f37 in Feval (form=136564662) at eval.c:2312
#60 0x081aa3dd in Fprogn (args=<optimized out>) at eval.c:343
#61 0x081aa66d in funcall_lambda (fun=136564414, nargs=4, arg_vector=0xbfffe244) at eval.c:3051
#62 0x081aa8a3 in Ffuncall (nargs=5, args=0xbfffe240) at eval.c:2930
#63 0x081aba4d in Fapply (nargs=2, args=0xbfffe2d8) at eval.c:2407
---Type <return> to continue, or q <return> to quit---
#64 0x081ab07d in apply1 (fn=136564414, arg=138926254) at eval.c:2645
#65 0x081a9f37 in Feval (form=138926246) at eval.c:2312
#66 0x081ccf81 in readevalloop (readcharfun=138603090, stream=0x84478d0, sourcename=138789065, printflag=0, 
    unibyte=138490170, readfun=138490170, start=138490170, end=138490170, evalfun=<optimized out>)
    at lread.c:1675
#67 0x081cda2a in Fload (file=138788953, noerror=138490170, nomessage=138490170, nosuffix=138490170, 
    must_suffix=138490170) at lread.c:1161
#68 0x081aa0ad in Feval (form=138745294) at eval.c:2265
#69 0x081ccf81 in readevalloop (readcharfun=138603090, stream=0x8446a10, sourcename=138613193, printflag=0, 
    unibyte=138490170, readfun=138490170, start=138490170, end=138490170, evalfun=<optimized out>)
    at lread.c:1675
#70 0x081cda2a in Fload (file=138613065, noerror=138490170, nomessage=138490170, nosuffix=138490170, 
    must_suffix=138490170) at lread.c:1161
#71 0x081aa0ad in Feval (form=138469934) at eval.c:2265
#72 0x0813e343 in top_level_2 () at keyboard.c:1137
#73 0x081a9011 in internal_condition_case (bfun=0x813e330 <top_level_2>, handlers=138521714, hfun=
    0x813f2a0 <cmd_error>) at eval.c:1407
#74 0x0813eb45 in top_level_1 (ignore=138490170) at keyboard.c:1145
#75 0x081a8f41 in internal_catch (tag=138519730, func=0x813eae0 <top_level_1>, arg=138490170) at eval.c:1154
#76 0x0813f453 in command_loop () at keyboard.c:1100
#77 0x0813f51b in recursive_edit_1 () at keyboard.c:730
#78 0x0813f642 in Frecursive_edit () at keyboard.c:792
#79 0x0813b4ac in main (argc=<optimized out>, argv=0xbfffee64) at emacs.c:1685

Lisp Backtrace:
"unless" (0xbfffcda8)
"backquote-process" (0xbfffce50)
"setq" (0xbfffcfe8)
"while" (0xbfffd0c8)
"let" (0xbfffd1f8)
"cond" (0xbfffd2b8)
"backquote-process" (0xbfffd360)
"setq" (0xbfffd4f8)
"while" (0xbfffd5d8)
"let" (0xbfffd708)
"cond" (0xbfffd7c8)
"backquote-process" (0xbfffd870)
"setq" (0xbfffda08)
"while" (0xbfffdae8)
"let" (0xbfffdc18)
"cond" (0xbfffdcd8)
"backquote-process" (0xbfffdd80)
"cdr" (0xbfffdef8)
0x823e078 Lisp type 6
"`" (0xbfffe118)
0x823ceb8 Lisp type 6
"defsubst" (0xbfffe368)
"load" (0xbfffe574)
"load" (0xbfffe7b4)

Re: compilation failure

[Werner LEMBERG]

> Can you try unoptimized build (with "-O0 -ggdb -g3")?  If that
> crashes as well, please show the backtrace from an unoptimized
> build, because backtraces from optimized builds cannot be trusted.

I did this:

  LC_ALL=C ./autogen.sh
  LC_ALL=C ./configure CFLAGS="-O0 -ggdb -g3"
  LC_ALL=C make bootstrap

and it succeeds...

> Btw, what version of GCC do you have on Ubuntu 10.10?

On my openSuSE box, gcc identies itself with

  gcc (SUSE Linux) 4.5.1 20101208 [gcc-4_5-branch revision 167585]

Perhaps this compiler version is buggy?


    Werner

Re: compilation failure

[Jim Meyering]

Eli Zaretskii wrote:
>> From: Jim Meyering <jim@meyering.net>
>> Date: Wed, 30 Mar 2011 09:42:42 +0200
>> Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org
>>
>> This command,
>>   env MALLOC_PERTURB_=0 MALLOC_CHECK_=0 make -j9 bootstrap
>> has succeeded for me on each of the last three mornings (Mar 28-30).
>>
>> I manually set those two MALLOC_*_ variables to 0 because
>> when I don't, emacs fails to bootstrap.
>
> It's a pity this problem was not reported to the bug tracker.  (At
> least I couldn't find it; apologies if I missed it.)

I thought I reported it to some emacs development list months ago,
but a quick search didn't find it.

>> I suspect that emacs is using free'd memory containing
>> values that would normally be unoffensive, but when you set
>> those envvars (esp MALLOC_PERTURB_) to nonzero, it makes
>> glibc scribble on free'd buffers, and that makes emacs
>> exhibit an actual failure.
>
> Can you use bisect to find the guilty commit?

Finding a commit for which a perturbed "make bootstrap" succeeds
was a challenge.

I bootstrapped 8 or 10 times, going back to 2009
in steps of 500, then 1500 commits.  Same failure
each time, until I started getting link errors:

  /usr/bin/ld: xftfont.o: undefined reference to symbol 'XRenderQueryExtension'
  /usr/bin/ld: note: 'XRenderQueryExtension' is defined in DSO /usr/lib64/libXrender.so.1 so try adding it to the linker command line
  /usr/lib64/libXrender.so.1: could not read symbols: Invalid operation

I worked around that by inserting -lXrender into the generated Makefile:

    perl -pi -e 's/(-lfreetype )/$1-lXrender /' src/Makefile

With that, I finally found a successful build at this git commit:

commit 84655cfe88efb24c256302d016cd037d22544cca
Author: Stefan Monnier <monnier@iro.umontreal.ca>
Date:   Fri Nov 6 18:47:48 2009 +0000

    Let integers use up 2 tags to give them one extra bit and double their range.
    * lisp.h (USE_2_TAGS_FOR_INTS): New macro.
    (LISP_INT_TAG, case_Lisp_Int, LISP_STRING_TAG, LISP_INT_TAG_P): New macros.
    ...

Maybe someone else will do the actual bisection:

    Bisecting: 4164 revisions left to test after this (roughly 12 steps)

This is the command to run:

    env MALLOC_PERTURB_=44 MALLOC_CHECK_=3 make -j9 bootstrap

If not, I'll get to it, eventually.

Re: compilation failure

[Eli Zaretskii]

> From: Jim Meyering <jim@meyering.net>
> Cc: wl@gnu.org,  eggert@cs.ucla.edu,  emacs-devel@gnu.org
> Date: Wed, 30 Mar 2011 15:41:33 +0200
> 
> > Can you use bisect to find the guilty commit?
> 
> Finding a commit for which a perturbed "make bootstrap" succeeds
> was a challenge.

Thanks for your efforts.

> With that, I finally found a successful build at this git commit:
> 
> commit 84655cfe88efb24c256302d016cd037d22544cca
> Author: Stefan Monnier <monnier@iro.umontreal.ca>
> Date:   Fri Nov 6 18:47:48 2009 +0000
> 
>     Let integers use up 2 tags to give them one extra bit and double their range.
>     * lisp.h (USE_2_TAGS_FOR_INTS): New macro.
>     (LISP_INT_TAG, case_Lisp_Int, LISP_STRING_TAG, LISP_INT_TAG_P): New macros.
>     ...
> 
> Maybe someone else will do the actual bisection:
> 
>     Bisecting: 4164 revisions left to test after this (roughly 12 steps)
> 
> This is the command to run:
> 
>     env MALLOC_PERTURB_=44 MALLOC_CHECK_=3 make -j9 bootstrap

I hope someone else can reproduce the problem.

Re: compilation failure

[Eli Zaretskii]

> From: Jim Meyering <jim@meyering.net>
> Cc: wl@gnu.org,  eggert@cs.ucla.edu,  emacs-devel@gnu.org
> Date: Wed, 30 Mar 2011 15:41:33 +0200
> 
> > Can you use bisect to find the guilty commit?
> 
> Finding a commit for which a perturbed "make bootstrap" succeeds
> was a challenge.

Thanks for your efforts.

> With that, I finally found a successful build at this git commit:
> 
> commit 84655cfe88efb24c256302d016cd037d22544cca
> Author: Stefan Monnier <monnier@iro.umontreal.ca>
> Date:   Fri Nov 6 18:47:48 2009 +0000
> 
>     Let integers use up 2 tags to give them one extra bit and double their range.
>     * lisp.h (USE_2_TAGS_FOR_INTS): New macro.
>     (LISP_INT_TAG, case_Lisp_Int, LISP_STRING_TAG, LISP_INT_TAG_P): New macros.
>     ...
> 
> Maybe someone else will do the actual bisection:
> 
>     Bisecting: 4164 revisions left to test after this (roughly 12 steps)
> 
> This is the command to run:
> 
>     env MALLOC_PERTURB_=44 MALLOC_CHECK_=3 make -j9 bootstrap

I hope someone else can reproduce the problem.

In any case, please report this to the bug tracker with all the
details, so it doesn't get forgotten.

Re: compilation failure

[Eli Zaretskii]

> Date: Wed, 30 Mar 2011 15:00:29 +0200 (CEST)
> Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org
> From: Werner LEMBERG <wl@gnu.org>
> 
> 
> > Can you try unoptimized build (with "-O0 -ggdb -g3")?  If that
> > crashes as well, please show the backtrace from an unoptimized
> > build, because backtraces from optimized builds cannot be trusted.
> 
> I did this:
> 
>   LC_ALL=C ./autogen.sh
>   LC_ALL=C ./configure CFLAGS="-O0 -ggdb -g3"
>   LC_ALL=C make bootstrap
> 
> and it succeeds...

Darn!

> On my openSuSE box, gcc identies itself with
> 
>   gcc (SUSE Linux) 4.5.1 20101208 [gcc-4_5-branch revision 167585]
> 
> Perhaps this compiler version is buggy?

Could be.  If you can try a different version, please do.