* compilation failure
@ 2011-03-30 6:13 Werner LEMBERG
2011-03-30 6:31 ` Paul Eggert
0 siblings, 1 reply; 14+ messages in thread
From: Werner LEMBERG @ 2011-03-30 6:13 UTC (permalink / raw
To: emacs-devel
[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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: compilation failure
2011-03-30 6:13 compilation failure Werner LEMBERG
@ 2011-03-30 6:31 ` Paul Eggert
2011-03-30 6:52 ` Werner LEMBERG
0 siblings, 1 reply; 14+ messages in thread
From: Paul Eggert @ 2011-03-30 6:31 UTC (permalink / raw
To: Werner LEMBERG; +Cc: emacs-devel
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).
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: compilation failure
2011-03-30 6:31 ` Paul Eggert
@ 2011-03-30 6:52 ` Werner LEMBERG
2011-03-30 7:42 ` Jim Meyering
2011-03-30 11:25 ` Eli Zaretskii
0 siblings, 2 replies; 14+ messages in thread
From: Werner LEMBERG @ 2011-03-30 6:52 UTC (permalink / raw
To: eggert; +Cc: emacs-devel
>> 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)
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: compilation failure
2011-03-30 6:52 ` Werner LEMBERG
@ 2011-03-30 7:42 ` Jim Meyering
2011-03-30 8:04 ` Werner LEMBERG
2011-03-30 11:35 ` Eli Zaretskii
2011-03-30 11:25 ` Eli Zaretskii
1 sibling, 2 replies; 14+ messages in thread
From: Jim Meyering @ 2011-03-30 7:42 UTC (permalink / raw
To: Werner LEMBERG; +Cc: eggert, emacs-devel
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: compilation failure
2011-03-30 7:42 ` Jim Meyering
@ 2011-03-30 8:04 ` Werner LEMBERG
2011-03-30 11:37 ` Eli Zaretskii
2011-03-30 11:35 ` Eli Zaretskii
1 sibling, 1 reply; 14+ messages in thread
From: Werner LEMBERG @ 2011-03-30 8:04 UTC (permalink / raw
To: jim; +Cc: eggert, emacs-devel
> 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: compilation failure
2011-03-30 6:52 ` Werner LEMBERG
2011-03-30 7:42 ` Jim Meyering
@ 2011-03-30 11:25 ` Eli Zaretskii
2011-03-30 13:00 ` Werner LEMBERG
1 sibling, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2011-03-30 11:25 UTC (permalink / raw
To: Werner LEMBERG; +Cc: eggert, emacs-devel
> 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?
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: compilation failure
2011-03-30 7:42 ` Jim Meyering
2011-03-30 8:04 ` Werner LEMBERG
@ 2011-03-30 11:35 ` Eli Zaretskii
2011-03-30 13:41 ` Jim Meyering
1 sibling, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2011-03-30 11:35 UTC (permalink / raw
To: Jim Meyering; +Cc: emacs-devel, eggert
> 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?
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: compilation failure
2011-03-30 8:04 ` Werner LEMBERG
@ 2011-03-30 11:37 ` Eli Zaretskii
2011-03-30 12:29 ` Werner LEMBERG
0 siblings, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2011-03-30 11:37 UTC (permalink / raw
To: Werner LEMBERG; +Cc: eggert, jim, emacs-devel
> 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?
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: compilation failure
2011-03-30 11:37 ` Eli Zaretskii
@ 2011-03-30 12:29 ` Werner LEMBERG
0 siblings, 0 replies; 14+ messages in thread
From: Werner LEMBERG @ 2011-03-30 12:29 UTC (permalink / raw
To: eliz; +Cc: eggert, jim, emacs-devel
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)
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: compilation failure
2011-03-30 11:25 ` Eli Zaretskii
@ 2011-03-30 13:00 ` Werner LEMBERG
2011-03-30 18:17 ` Eli Zaretskii
0 siblings, 1 reply; 14+ messages in thread
From: Werner LEMBERG @ 2011-03-30 13:00 UTC (permalink / raw
To: eliz; +Cc: eggert, emacs-devel
> 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: compilation failure
2011-03-30 11:35 ` Eli Zaretskii
@ 2011-03-30 13:41 ` Jim Meyering
2011-03-30 18:16 ` Eli Zaretskii
2011-03-30 18:16 ` Eli Zaretskii
0 siblings, 2 replies; 14+ messages in thread
From: Jim Meyering @ 2011-03-30 13:41 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel, eggert
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: compilation failure
2011-03-30 13:41 ` Jim Meyering
@ 2011-03-30 18:16 ` Eli Zaretskii
2011-03-30 18:16 ` Eli Zaretskii
1 sibling, 0 replies; 14+ messages in thread
From: Eli Zaretskii @ 2011-03-30 18:16 UTC (permalink / raw
To: Jim Meyering; +Cc: emacs-devel, eggert
> 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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: compilation failure
2011-03-30 13:41 ` Jim Meyering
2011-03-30 18:16 ` Eli Zaretskii
@ 2011-03-30 18:16 ` Eli Zaretskii
1 sibling, 0 replies; 14+ messages in thread
From: Eli Zaretskii @ 2011-03-30 18:16 UTC (permalink / raw
To: Jim Meyering; +Cc: emacs-devel, eggert
> 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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: compilation failure
2011-03-30 13:00 ` Werner LEMBERG
@ 2011-03-30 18:17 ` Eli Zaretskii
0 siblings, 0 replies; 14+ messages in thread
From: Eli Zaretskii @ 2011-03-30 18:17 UTC (permalink / raw
To: Werner LEMBERG; +Cc: eggert, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2011-03-30 18:17 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-03-30 6:13 compilation failure Werner LEMBERG
2011-03-30 6:31 ` Paul Eggert
2011-03-30 6:52 ` Werner LEMBERG
2011-03-30 7:42 ` Jim Meyering
2011-03-30 8:04 ` Werner LEMBERG
2011-03-30 11:37 ` Eli Zaretskii
2011-03-30 12:29 ` Werner LEMBERG
2011-03-30 11:35 ` Eli Zaretskii
2011-03-30 13:41 ` Jim Meyering
2011-03-30 18:16 ` Eli Zaretskii
2011-03-30 18:16 ` Eli Zaretskii
2011-03-30 11:25 ` Eli Zaretskii
2011-03-30 13:00 ` Werner LEMBERG
2011-03-30 18:17 ` Eli Zaretskii
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.