* bug#6031: gcc 4.5 breaks optimized builds of emacs
@ 2010-04-24 23:44 Elias Pipping
2010-04-25 3:07 ` Dan Nicolaescu
` (4 more replies)
0 siblings, 5 replies; 15+ messages in thread
From: Elias Pipping @ 2010-04-24 23:44 UTC (permalink / raw
To: 6031
Hi,
I'm on the current HEAD of the repo.or.cz mirror of emacs which is
http://repo.or.cz/w/emacs.git/commit/910daaa95ca0708ad7022667e214bba4b8eb3d6b
When I compile a minimal version of emacs like this:
$ ./configure CFLAGS="-O1 -foptimize-sibling-calls" --without-x
--without-alsa --without-dbus; [..]
with gcc 4.5 and run it via
$ ./src/emacs -Q -nw
I get a segfault. Dropping the -foptimize-sibling-calls (which is
implied by -O2) makes it work again. So does using an older version of
gcc (e.g. 4.4.3) or running emacs outside a terminal.
$ gdb ./src/emacs
GNU gdb (GDB) 7.1
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/pipping/emacs/src/emacs...done.
(gdb) run -Q -nw
< clears terminal >
Program received signal SIGSEGV, Segmentation fault.
0x0000000000406015 in fill_up_glyph_row_area_with_spaces
(row=0x111e320, area=2) at dispnew.c:2910
2910 *text++ = space_glyph;
(gdb) bt
#0 0x0000000000406015 in fill_up_glyph_row_area_with_spaces
(row=0x111e320, area=2) at dispnew.c:2910
#1 0x000000000040a6a8 in fill_up_glyph_row_with_spaces
(matrix=0xde7290, w=0xb4a630) at dispnew.c:2892
#2 build_frame_matrix_from_leaf_window (matrix=0xde7290, w=0xb4a630)
at dispnew.c:2790
#3 build_frame_matrix_from_window_tree (matrix=0xde7290, w=0xb4a630)
at dispnew.c:2718
#4 0x000000000040c51c in build_frame_matrix (f=0xb4a3b0, force_p=1,
inhibit_hairy_id_p=1) at dispnew.c:2698
#5 update_frame (f=0xb4a3b0, force_p=1, inhibit_hairy_id_p=1) at dispnew.c:3560
#6 0x0000000000426340 in echo_area_display (update_frame_p=1) at xdisp.c:9624
#7 0x0000000000426601 in message3_nolog (m=16043489, nbytes=65,
multibyte=0) at xdisp.c:8479
#8 0x00000000004267d0 in message3 (m=16043489, nbytes=65,
multibyte=0) at xdisp.c:8414
#9 0x00000000004d3bf7 in Fmessage (nargs=<value optimized out>,
args=<value optimized out>) at editfns.c:3408
#10 0x00000000004d976c in Ffuncall (nargs=<value optimized out>,
args=0x7fffffffd510) at eval.c:3054
#11 0x000000000050bde9 in Fbyte_code (bytestr=<value optimized out>,
vector=<value optimized out>, maxdepth=<value optimized out>) at
bytecode.c:680
#12 0x00000000004dbca2 in funcall_lambda (fun=8298757, nargs=0,
arg_vector=0x7fffffffd6d8) at eval.c:3260
#13 0x00000000004d9949 in Ffuncall (nargs=<value optimized out>,
args=0x7fffffffd6d0) at eval.c:3119
#14 0x000000000050bde9 in Fbyte_code (bytestr=<value optimized out>,
vector=<value optimized out>, maxdepth=<value optimized out>) at
bytecode.c:680
#15 0x00000000004dbca2 in funcall_lambda (fun=8300205, nargs=1,
arg_vector=0x7fffffffd8c8) at eval.c:3260
#16 0x00000000004d9949 in Ffuncall (nargs=<value optimized out>,
args=0x7fffffffd8c0) at eval.c:3119
#17 0x000000000050bde9 in Fbyte_code (bytestr=<value optimized out>,
vector=<value optimized out>, maxdepth=<value optimized out>) at
bytecode.c:680
#18 0x00000000004dbca2 in funcall_lambda (fun=8273333, nargs=0,
arg_vector=0x7fffffffdaa8) at eval.c:3260
#19 0x00000000004d9949 in Ffuncall (nargs=<value optimized out>,
args=0x7fffffffdaa0) at eval.c:3119
#20 0x000000000050bde9 in Fbyte_code (bytestr=<value optimized out>,
vector=<value optimized out>, maxdepth=<value optimized out>) at
bytecode.c:680
#21 0x00000000004dbca2 in funcall_lambda (fun=8268357, nargs=0,
arg_vector=0x7fffffffdbe0) at eval.c:3260
#22 0x00000000004dbd87 in apply_lambda (fun=8268357, args=<value
optimized out>, eval_flag=1) at eval.c:3184
#23 0x00000000004db750 in Feval (form=<value optimized out>) at eval.c:2410
#24 0x00000000004d8dc4 in internal_condition_case (bfun=0x474709
<top_level_2>, handlers=11756482, hfun=0x474faf <cmd_error>) at
eval.c:1512
#25 0x0000000000474bdb in top_level_1 () at keyboard.c:1373
#26 0x00000000004d8c94 in internal_catch (tag=11752306, func=0x474bb1
<top_level_1>, arg=11704658) at eval.c:1248
#27 0x000000000047513a in command_loop () at keyboard.c:1328
#28 0x00000000004751ee in recursive_edit_1 () at keyboard.c:950
#29 0x0000000000475338 in Frecursive_edit () at keyboard.c:1012
#30 0x0000000000472747 in main (argc=<value optimized out>,
argv=0x7fffffffe418) at emacs.c:1784
(gdb)
Kind Regards,
Elias Pipping
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#6031: gcc 4.5 breaks optimized builds of emacs
2010-04-24 23:44 bug#6031: gcc 4.5 breaks optimized builds of emacs Elias Pipping
@ 2010-04-25 3:07 ` Dan Nicolaescu
2010-04-25 11:12 ` Elias Pipping
2010-04-25 13:33 ` Eli Zaretskii
` (3 subsequent siblings)
4 siblings, 1 reply; 15+ messages in thread
From: Dan Nicolaescu @ 2010-04-25 3:07 UTC (permalink / raw
To: Elias Pipping; +Cc: 6031
Elias Pipping <pipping.elias@googlemail.com> writes:
> Hi,
>
> I'm on the current HEAD of the repo.or.cz mirror of emacs which is
>
> http://repo.or.cz/w/emacs.git/commit/910daaa95ca0708ad7022667e214bba4b8eb3d6b
>
> When I compile a minimal version of emacs like this:
>
> $ ./configure CFLAGS="-O1 -foptimize-sibling-calls" --without-x
> --without-alsa --without-dbus; [..]
>
> with gcc 4.5 and run it via
>
> $ ./src/emacs -Q -nw
>
> I get a segfault. Dropping the -foptimize-sibling-calls (which is
> implied by -O2) makes it work again. So does using an older version of
> gcc (e.g. 4.4.3) or running emacs outside a terminal.
Can you please uncomment this line in emacs/src/s/intel386.h
/* #define NO_ARG_ARRAY */
recompile everything and see if you get the problem after that.
>
>
> $ gdb ./src/emacs
> GNU gdb (GDB) 7.1
> Copyright (C) 2010 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-pc-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /home/pipping/emacs/src/emacs...done.
> (gdb) run -Q -nw
>
> < clears terminal >
>
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000000000406015 in fill_up_glyph_row_area_with_spaces
> (row=0x111e320, area=2) at dispnew.c:2910
> 2910 *text++ = space_glyph;
> (gdb) bt
> #0 0x0000000000406015 in fill_up_glyph_row_area_with_spaces
> (row=0x111e320, area=2) at dispnew.c:2910
> #1 0x000000000040a6a8 in fill_up_glyph_row_with_spaces
> (matrix=0xde7290, w=0xb4a630) at dispnew.c:2892
> #2 build_frame_matrix_from_leaf_window (matrix=0xde7290, w=0xb4a630)
> at dispnew.c:2790
> #3 build_frame_matrix_from_window_tree (matrix=0xde7290, w=0xb4a630)
> at dispnew.c:2718
> #4 0x000000000040c51c in build_frame_matrix (f=0xb4a3b0, force_p=1,
> inhibit_hairy_id_p=1) at dispnew.c:2698
> #5 update_frame (f=0xb4a3b0, force_p=1, inhibit_hairy_id_p=1) at dispnew.c:3560
> #6 0x0000000000426340 in echo_area_display (update_frame_p=1) at xdisp.c:9624
> #7 0x0000000000426601 in message3_nolog (m=16043489, nbytes=65,
> multibyte=0) at xdisp.c:8479
> #8 0x00000000004267d0 in message3 (m=16043489, nbytes=65,
> multibyte=0) at xdisp.c:8414
> #9 0x00000000004d3bf7 in Fmessage (nargs=<value optimized out>,
> args=<value optimized out>) at editfns.c:3408
> #10 0x00000000004d976c in Ffuncall (nargs=<value optimized out>,
> args=0x7fffffffd510) at eval.c:3054
> #11 0x000000000050bde9 in Fbyte_code (bytestr=<value optimized out>,
> vector=<value optimized out>, maxdepth=<value optimized out>) at
> bytecode.c:680
> #12 0x00000000004dbca2 in funcall_lambda (fun=8298757, nargs=0,
> arg_vector=0x7fffffffd6d8) at eval.c:3260
> #13 0x00000000004d9949 in Ffuncall (nargs=<value optimized out>,
> args=0x7fffffffd6d0) at eval.c:3119
> #14 0x000000000050bde9 in Fbyte_code (bytestr=<value optimized out>,
> vector=<value optimized out>, maxdepth=<value optimized out>) at
> bytecode.c:680
> #15 0x00000000004dbca2 in funcall_lambda (fun=8300205, nargs=1,
> arg_vector=0x7fffffffd8c8) at eval.c:3260
> #16 0x00000000004d9949 in Ffuncall (nargs=<value optimized out>,
> args=0x7fffffffd8c0) at eval.c:3119
> #17 0x000000000050bde9 in Fbyte_code (bytestr=<value optimized out>,
> vector=<value optimized out>, maxdepth=<value optimized out>) at
> bytecode.c:680
> #18 0x00000000004dbca2 in funcall_lambda (fun=8273333, nargs=0,
> arg_vector=0x7fffffffdaa8) at eval.c:3260
> #19 0x00000000004d9949 in Ffuncall (nargs=<value optimized out>,
> args=0x7fffffffdaa0) at eval.c:3119
> #20 0x000000000050bde9 in Fbyte_code (bytestr=<value optimized out>,
> vector=<value optimized out>, maxdepth=<value optimized out>) at
> bytecode.c:680
> #21 0x00000000004dbca2 in funcall_lambda (fun=8268357, nargs=0,
> arg_vector=0x7fffffffdbe0) at eval.c:3260
> #22 0x00000000004dbd87 in apply_lambda (fun=8268357, args=<value
> optimized out>, eval_flag=1) at eval.c:3184
> #23 0x00000000004db750 in Feval (form=<value optimized out>) at eval.c:2410
> #24 0x00000000004d8dc4 in internal_condition_case (bfun=0x474709
> <top_level_2>, handlers=11756482, hfun=0x474faf <cmd_error>) at
> eval.c:1512
> #25 0x0000000000474bdb in top_level_1 () at keyboard.c:1373
> #26 0x00000000004d8c94 in internal_catch (tag=11752306, func=0x474bb1
> <top_level_1>, arg=11704658) at eval.c:1248
> #27 0x000000000047513a in command_loop () at keyboard.c:1328
> #28 0x00000000004751ee in recursive_edit_1 () at keyboard.c:950
> #29 0x0000000000475338 in Frecursive_edit () at keyboard.c:1012
> #30 0x0000000000472747 in main (argc=<value optimized out>,
> argv=0x7fffffffe418) at emacs.c:1784
> (gdb)
>
>
> Kind Regards,
>
> Elias Pipping
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#6031: gcc 4.5 breaks optimized builds of emacs
2010-04-25 3:07 ` Dan Nicolaescu
@ 2010-04-25 11:12 ` Elias Pipping
0 siblings, 0 replies; 15+ messages in thread
From: Elias Pipping @ 2010-04-25 11:12 UTC (permalink / raw
To: Dan Nicolaescu; +Cc: 6031
On Sun, Apr 25, 2010 at 5:07 AM, Dan Nicolaescu <dann@gnu.org> wrote:
> Elias Pipping <pipping.elias@googlemail.com> writes:
>
>> Hi,
>>
>> I'm on the current HEAD of the repo.or.cz mirror of emacs which is
>>
>> http://repo.or.cz/w/emacs.git/commit/910daaa95ca0708ad7022667e214bba4b8eb3d6b
>>
>> When I compile a minimal version of emacs like this:
>>
>> $ ./configure CFLAGS="-O1 -foptimize-sibling-calls" --without-x
>> --without-alsa --without-dbus; [..]
>>
>> with gcc 4.5 and run it via
>>
>> $ ./src/emacs -Q -nw
>>
>> I get a segfault. Dropping the -foptimize-sibling-calls (which is
>> implied by -O2) makes it work again. So does using an older version of
>> gcc (e.g. 4.4.3) or running emacs outside a terminal.
>
> Can you please uncomment this line in emacs/src/s/intel386.h
> /* #define NO_ARG_ARRAY */
>
> recompile everything and see if you get the problem after that.
Hi!
no -- assuming you meant src/m/intel386.h and thus
--- src/m/intel386.h~ 2010-04-24 15:24:25.000000000 +0200
+++ src/m/intel386.h 2010-04-25 13:07:01.555119059 +0200
@@ -42,7 +42,7 @@
/* Define NO_ARG_ARRAY if you cannot take the address of the first of a
* group of arguments and treat it as an array of the arguments. */
-/* #define NO_ARG_ARRAY */
+#define NO_ARG_ARRAY
#ifdef USG
#define TEXT_START 0
that doesn't appear to help.
Kind regards,
Elias Pipping
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#6031: gcc 4.5 breaks optimized builds of emacs
2010-04-24 23:44 bug#6031: gcc 4.5 breaks optimized builds of emacs Elias Pipping
2010-04-25 3:07 ` Dan Nicolaescu
@ 2010-04-25 13:33 ` Eli Zaretskii
2010-04-25 14:56 ` Elias Pipping
2010-04-25 18:32 ` Chong Yidong
` (2 subsequent siblings)
4 siblings, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2010-04-25 13:33 UTC (permalink / raw
To: Elias Pipping; +Cc: 6031
> From: Elias Pipping <pipping.elias@googlemail.com>
> Date: Sun, 25 Apr 2010 01:44:14 +0200
> Cc:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000000000406015 in fill_up_glyph_row_area_with_spaces
> (row=0x111e320, area=2) at dispnew.c:2910
> 2910 *text++ = space_glyph;
Please show the values of the following variables in frame 0:
(gdb) p text
(gdb) p end
(gdb) p row->used[area]
Thanks.
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#6031: gcc 4.5 breaks optimized builds of emacs
2010-04-25 13:33 ` Eli Zaretskii
@ 2010-04-25 14:56 ` Elias Pipping
2010-04-25 16:15 ` Eli Zaretskii
0 siblings, 1 reply; 15+ messages in thread
From: Elias Pipping @ 2010-04-25 14:56 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 6031
On Sun, Apr 25, 2010 at 3:33 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Elias Pipping <pipping.elias@googlemail.com>
>> Date: Sun, 25 Apr 2010 01:44:14 +0200
>> Cc:
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x0000000000406015 in fill_up_glyph_row_area_with_spaces
>> (row=0x111e320, area=2) at dispnew.c:2910
>> 2910 *text++ = space_glyph;
>
> Please show the values of the following variables in frame 0:
>
> (gdb) p text
> (gdb) p end
> (gdb) p row->used[area]
>
> Thanks.
(gdb) p text
$1 = (struct glyph *) 0x1163000
(gdb) p end
$2 = (struct glyph *) 0x7ffff73525fa
(gdb) p *end
$3 = {charpos = -19543819183790871, object = 4904358129765974015,
pixel_width = -30270, ascent = -29241,
descent = 327, voffset = -28477, type = 0, multibyte_p = 0,
left_box_line_p = 0, right_box_line_p = 1,
overlaps_vertically_p = 0, padding_p = 0, glyph_not_available_p = 1,
avoid_cursor_p = 0, resolved_level = 8,
bidi_type = 2, face_id = 37008, font_type = 1, slice = {x = 37008, y
= 37008, width = 37008, height = 65464}, u = {
ch = 1224736767, cmp = {automatic = 1, id = 8388607, from = 8, to
= 4}, img_id = 1224736767, stretch = {
height = 65535, ascent = 18687}, val = 1224736767}}
(gdb) p row->used[area]
$4 = 0
(gdb)
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#6031: gcc 4.5 breaks optimized builds of emacs
2010-04-25 14:56 ` Elias Pipping
@ 2010-04-25 16:15 ` Eli Zaretskii
2010-04-26 22:41 ` Elias Pipping
0 siblings, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2010-04-25 16:15 UTC (permalink / raw
To: Elias Pipping; +Cc: 6031
> From: Elias Pipping <pipping.elias@googlemail.com>
> Date: Sun, 25 Apr 2010 16:56:20 +0200
> Cc: 6031@debbugs.gnu.org
>
> (gdb) p text
> $1 = (struct glyph *) 0x1163000
> (gdb) p end
> $2 = (struct glyph *) 0x7ffff73525fa
Hmm... `end' looks entirely bogus to me... It should have been much
smalle. Can you set a watchpoint at the address of row->glyphs[3],
and see who puts there a non-null value? Here's how to do that:
In the crashed session:
(gdb) p &row->glyphs[3]
$1 = (struct glyph **) 0x12345678
Start a new session:
gdb ./emacs
(gdb) start -Q -nw
(gdb) watch *(struct glyph **) 0x12345678
(gdb) continue
0x12345678 is of course just an example, you will actually see some
other value.
You should see one change of the value here (line 673 in dispnew.c):
matrix->rows = (struct glyph_row *) xrealloc (matrix->rows, size);
bzero (matrix->rows + matrix->rows_allocated,
new_rows * sizeof *matrix->rows);
The value should change to a NULL pointer. You should then see
another change in the loop which starts on line 697 in dispnew.c:
for (i = 0; i < dim.height; ++i)
The value should change from a NULL pointer to something non-null.
There should be some more similar changes. Please see which one of
them puts the bogus value 0x7ffff73525fa or some such there.
Thanks.
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#6031: gcc 4.5 breaks optimized builds of emacs
2010-04-24 23:44 bug#6031: gcc 4.5 breaks optimized builds of emacs Elias Pipping
2010-04-25 3:07 ` Dan Nicolaescu
2010-04-25 13:33 ` Eli Zaretskii
@ 2010-04-25 18:32 ` Chong Yidong
2010-04-26 15:40 ` Elias Pipping
2010-04-26 20:17 ` bug#6031: Emacs 23.1 breaks with gcc 4.5 and -foptimize-sibling-calls Ulrich Mueller
2010-04-27 11:26 ` bug#6031: gcc 4.5 breaks optimized builds of emacs Ulrich Mueller
4 siblings, 1 reply; 15+ messages in thread
From: Chong Yidong @ 2010-04-25 18:32 UTC (permalink / raw
To: Elias Pipping; +Cc: 6031
Elias Pipping <pipping.elias@googlemail.com> writes:
> I'm on the current HEAD of the repo.or.cz mirror of emacs which is
>
> http://repo.or.cz/w/emacs.git/commit/910daaa95ca0708ad7022667e214bba4b8eb3d6b
>
> When I compile a minimal version of emacs like this:
>
> $ ./configure CFLAGS="-O1 -foptimize-sibling-calls" --without-x
> --without-alsa --without-dbus; [..]
>
> with gcc 4.5 and run it via
>
> $ ./src/emacs -Q -nw
>
> I get a segfault. Dropping the -foptimize-sibling-calls (which is
> implied by -O2) makes it work again. So does using an older version of
> gcc (e.g. 4.4.3) or running emacs outside a terminal.
Could you do me a favor, and check whether the problem also exists for
the latest emacs-23 pretest at ftp://alpha.gnu.org/gnu/emacs/pretest/ ?
Thanks.
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#6031: gcc 4.5 breaks optimized builds of emacs
2010-04-25 18:32 ` Chong Yidong
@ 2010-04-26 15:40 ` Elias Pipping
2010-04-26 17:40 ` Eli Zaretskii
2010-04-26 22:12 ` Elias Pipping
0 siblings, 2 replies; 15+ messages in thread
From: Elias Pipping @ 2010-04-26 15:40 UTC (permalink / raw
To: Chong Yidong; +Cc: 6031
On Sun, Apr 25, 2010 at 8:32 PM, Chong Yidong <cyd@stupidchicken.com> wrote:
> Elias Pipping <pipping.elias@googlemail.com> writes:
>
>> I'm on the current HEAD of the repo.or.cz mirror of emacs which is
>>
>> http://repo.or.cz/w/emacs.git/commit/910daaa95ca0708ad7022667e214bba4b8eb3d6b
>>
>> When I compile a minimal version of emacs like this:
>>
>> $ ./configure CFLAGS="-O1 -foptimize-sibling-calls" --without-x
>> --without-alsa --without-dbus; [..]
>>
>> with gcc 4.5 and run it via
>>
>> $ ./src/emacs -Q -nw
>>
>> I get a segfault. Dropping the -foptimize-sibling-calls (which is
>> implied by -O2) makes it work again. So does using an older version of
>> gcc (e.g. 4.4.3) or running emacs outside a terminal.
>
> Could you do me a favor, and check whether the problem also exists for
> the latest emacs-23 pretest at ftp://alpha.gnu.org/gnu/emacs/pretest/ ?
It does not. Judging by the bisecting I did, the problem was introduced in
http://repo.or.cz/w/emacs.git/commit/5a98a2a69b1a15173ce4bfa53307608a7150b407
Kind regards,
Elias
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#6031: gcc 4.5 breaks optimized builds of emacs
2010-04-26 15:40 ` Elias Pipping
@ 2010-04-26 17:40 ` Eli Zaretskii
2010-04-26 22:12 ` Elias Pipping
1 sibling, 0 replies; 15+ messages in thread
From: Eli Zaretskii @ 2010-04-26 17:40 UTC (permalink / raw
To: Elias Pipping; +Cc: 6031, cyd
> From: Elias Pipping <pipping.elias@googlemail.com>
> Date: Mon, 26 Apr 2010 17:40:40 +0200
> Cc: 6031@debbugs.gnu.org
>
> > Could you do me a favor, and check whether the problem also exists for
> > the latest emacs-23 pretest at ftp://alpha.gnu.org/gnu/emacs/pretest/ ?
>
> It does not. Judging by the bisecting I did, the problem was introduced in
>
> http://repo.or.cz/w/emacs.git/commit/5a98a2a69b1a15173ce4bfa53307608a7150b407
How to map this to Bazaar revnos or rev-ids?
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#6031: Emacs 23.1 breaks with gcc 4.5 and -foptimize-sibling-calls
2010-04-24 23:44 bug#6031: gcc 4.5 breaks optimized builds of emacs Elias Pipping
` (2 preceding siblings ...)
2010-04-25 18:32 ` Chong Yidong
@ 2010-04-26 20:17 ` Ulrich Mueller
2010-04-26 21:09 ` Dan Nicolaescu
2010-04-27 11:26 ` bug#6031: gcc 4.5 breaks optimized builds of emacs Ulrich Mueller
4 siblings, 1 reply; 15+ messages in thread
From: Ulrich Mueller @ 2010-04-26 20:17 UTC (permalink / raw
To: 6031
I just want to point out that we observe a very similar issue in
<http://bugs.gentoo.org/317187>, for the 23.1 release.
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#6031: Emacs 23.1 breaks with gcc 4.5 and -foptimize-sibling-calls
2010-04-26 20:17 ` bug#6031: Emacs 23.1 breaks with gcc 4.5 and -foptimize-sibling-calls Ulrich Mueller
@ 2010-04-26 21:09 ` Dan Nicolaescu
0 siblings, 0 replies; 15+ messages in thread
From: Dan Nicolaescu @ 2010-04-26 21:09 UTC (permalink / raw
To: Ulrich Mueller; +Cc: 6031
Ulrich Mueller <ulm@gentoo.org> writes:
> I just want to point out that we observe a very similar issue in
> <http://bugs.gentoo.org/317187>, for the 23.1 release.
Could you please try to find out where exactly the problem is?
You can do a binary search on the object files compiled with the
options that result in a working binary by linking them with the ones
that result in a non-working binary.
Maybe you can find a single file that gets miscompiled, and then
find out what function in that file gets miscompiled.
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#6031: gcc 4.5 breaks optimized builds of emacs
2010-04-26 15:40 ` Elias Pipping
2010-04-26 17:40 ` Eli Zaretskii
@ 2010-04-26 22:12 ` Elias Pipping
1 sibling, 0 replies; 15+ messages in thread
From: Elias Pipping @ 2010-04-26 22:12 UTC (permalink / raw
To: Chong Yidong; +Cc: 6031
On Mon, Apr 26, 2010 at 5:40 PM, Elias Pipping
<pipping.elias@googlemail.com> wrote:
> On Sun, Apr 25, 2010 at 8:32 PM, Chong Yidong <cyd@stupidchicken.com> wrote:
>> Could you do me a favor, and check whether the problem also exists for
>> the latest emacs-23 pretest at ftp://alpha.gnu.org/gnu/emacs/pretest/ ?
>
> It does not. Judging by the bisecting I did, the problem was introduced in
>
> http://repo.or.cz/w/emacs.git/commit/5a98a2a69b1a15173ce4bfa53307608a7150b407
>
>
> Kind regards,
>
> Elias
A slightly different version of this problem does appear in 23.1.96,
though. A segfault when running in a terminal. This one doesn't occur
right after the start, though. To trigger it, press C-x C-f and press
<tab> four times. Here's what happens then:
Program received signal SIGSEGV, Segmentation fault.
build_frame_matrix_from_leaf_window (matrix=0xca5e30, w=0xa93f90) at
dispnew.c:2824
2824 SET_CHAR_GLYPH_FROM_GLYPH (*border, right_border_glyph);
(gdb) bt
#0 build_frame_matrix_from_leaf_window (matrix=0xca5e30, w=0xa93f90)
at dispnew.c:2824
#1 build_frame_matrix_from_window_tree (matrix=0xca5e30, w=0xa93f90)
at dispnew.c:2720
#2 0x0000000000409601 in build_frame_matrix_from_window_tree
(matrix=0xca5e30, w=0xf0a800) at dispnew.c:2716
#3 0x000000000040c24d in build_frame_matrix (f=0xa93d10, force_p=0,
inhibit_hairy_id_p=0) at dispnew.c:2700
#4 update_frame (f=0xa93d10, force_p=0, inhibit_hairy_id_p=0) at dispnew.c:3951
#5 0x0000000000423c82 in redisplay_internal
(preserve_echo_area=<value optimized out>) at xdisp.c:11826
#6 0x00000000004769d5 in read_char (commandflag=1, nmaps=2,
maps=0x7fffffffcdf0, prev_event=10938770,
used_mouse_menu=0x7fffffffce74, end_time=0x0) at keyboard.c:2727
#7 0x00000000004790ed in read_key_sequence (keybuf=0x7fffffffcfa0,
bufsize=30, prompt=10938770, dont_downcase_last=0,
can_return_switch_frame=1, fix_current_buffer=1)
at keyboard.c:9512
#8 0x000000000047aef1 in command_loop_1 () at keyboard.c:1643
#9 0x00000000004d41b4 in internal_condition_case (bfun=0x47ac15
<command_loop_1>, handlers=11006002, hfun=0x470aa2 <cmd_error>) at
eval.c:1490
#10 0x000000000046ff66 in command_loop_2 () at keyboard.c:1360
#11 0x00000000004d4084 in internal_catch (tag=11103042, func=0x46ff4c
<command_loop_2>, arg=10938770) at eval.c:1226
#12 0x0000000000470c02 in command_loop () at keyboard.c:1325
#13 0x0000000000470ce1 in recursive_edit_1 () at keyboard.c:954
#14 0x0000000000498809 in read_minibuf (map=10932022,
initial=13617857, prompt=<value optimized out>, backup_n=<value
optimized out>, expflag=0, histvar=<value optimized out>,
histpos=0, defalt=15330225, allow_props=0, inherit_input_method=0)
at minibuf.c:740
#15 0x0000000000498c78 in Fcompleting_read (prompt=8075209,
collection=<value optimized out>, predicate=<value optimized out>,
require_match=11074946,
initial_input=<value optimized out>, hist=11015314, def=15330225,
inherit_input_method=10938770) at minibuf.c:1824
#16 0x00000000004d4d25 in Ffuncall (nargs=<value optimized out>,
args=0x7fffffffd4a8) at eval.c:3055
#17 0x000000000050736f in Fbyte_code (bytestr=<value optimized out>,
vector=<value optimized out>, maxdepth=<value optimized out>) at
bytecode.c:680
#18 0x00000000004d6fbc in funcall_lambda (fun=8282029, nargs=4,
arg_vector=0x7fffffffd778) at eval.c:3211
#19 0x00000000004d4d43 in Ffuncall (nargs=<value optimized out>,
args=0x7fffffffd770) at eval.c:3070
#20 0x000000000050736f in Fbyte_code (bytestr=<value optimized out>,
vector=<value optimized out>, maxdepth=<value optimized out>) at
bytecode.c:680
#21 0x00000000004d6fbc in funcall_lambda (fun=8074637, nargs=2,
arg_vector=0x7fffffffd948) at eval.c:3211
#22 0x00000000004d4d43 in Ffuncall (nargs=<value optimized out>,
args=0x7fffffffd940) at eval.c:3070
#23 0x000000000050736f in Fbyte_code (bytestr=<value optimized out>,
vector=<value optimized out>, maxdepth=<value optimized out>) at
bytecode.c:680
#24 0x00000000004d6948 in Feval (form=<value optimized out>) at eval.c:2352
#25 0x00000000004d1e42 in Fcall_interactively (function=11460274,
record_flag=10938770, keys=10997285) at callint.c:365
#26 0x00000000004d4c42 in Ffuncall (nargs=<value optimized out>,
args=0x7fffffffdcd0) at eval.c:3030
#27 0x00000000004d4ee7 in call3 (fn=<value optimized out>, arg1=<value
optimized out>, arg2=<value optimized out>, arg3=<value optimized
out>) at eval.c:2850
#28 0x000000000047bc01 in command_loop_1 () at keyboard.c:1904
#29 0x00000000004d41b4 in internal_condition_case (bfun=0x47ac15
<command_loop_1>, handlers=11006002, hfun=0x470aa2 <cmd_error>) at
eval.c:1490
#30 0x000000000046ff66 in command_loop_2 () at keyboard.c:1360
#31 0x00000000004d4084 in internal_catch (tag=10998562, func=0x46ff4c
<command_loop_2>, arg=10938770) at eval.c:1226
#32 0x0000000000470c45 in command_loop () at keyboard.c:1339
#33 0x0000000000470ce1 in recursive_edit_1 () at keyboard.c:954
#34 0x0000000000470e2b in Frecursive_edit () at keyboard.c:1016
#35 0x000000000046db57 in main (argc=<value optimized out>,
argv=0x7fffffffe538) at emacs.c:1833
(gdb)
this is with the same CC and CFLAGS as mentioned before (changing
either appears to make the bug go away).
Kind regards,
Elias
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#6031: gcc 4.5 breaks optimized builds of emacs
2010-04-25 16:15 ` Eli Zaretskii
@ 2010-04-26 22:41 ` Elias Pipping
0 siblings, 0 replies; 15+ messages in thread
From: Elias Pipping @ 2010-04-26 22:41 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 6031
On Sun, Apr 25, 2010 at 6:15 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Elias Pipping <pipping.elias@googlemail.com>
>> Date: Sun, 25 Apr 2010 16:56:20 +0200
>> Cc: 6031@debbugs.gnu.org
>>
>> (gdb) p text
>> $1 = (struct glyph *) 0x1163000
>> (gdb) p end
>> $2 = (struct glyph *) 0x7ffff73525fa
>
> Hmm... `end' looks entirely bogus to me... It should have been much
> smalle. Can you set a watchpoint at the address of row->glyphs[3],
> and see who puts there a non-null value? Here's how to do that:
>
> In the crashed session:
> (gdb) p &row->glyphs[3]
> $1 = (struct glyph **) 0x12345678
>
> Start a new session:
> gdb ./emacs
> (gdb) start -Q -nw
> (gdb) watch *(struct glyph **) 0x12345678
> (gdb) continue
>
> 0x12345678 is of course just an example, you will actually see some
> other value.
(after quite a couple of changes to it):
Hardware watchpoint 2: *(struct glyph **) 0x1126868
Old value = (struct glyph *) 0xa35312d39353838
New value = (struct glyph *) 0x0
0x00007ffff7639f58 in memset () from /lib/libc.so.6
(gdb)
after that, before the watchpoint is hit again, the segfault occurs.
> You should see one change of the value here (line 673 in dispnew.c):
>
> matrix->rows = (struct glyph_row *) xrealloc (matrix->rows, size);
> bzero (matrix->rows + matrix->rows_allocated,
> new_rows * sizeof *matrix->rows);
>
> The value should change to a NULL pointer. You should then see
> another change in the loop which starts on line 697 in dispnew.c:
>
> for (i = 0; i < dim.height; ++i)
>
> The value should change from a NULL pointer to something non-null.
>
> There should be some more similar changes. Please see which one of
> them puts the bogus value 0x7ffff73525fa or some such there.
>
> Thanks.
Kind regards,
Elias
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#6031: gcc 4.5 breaks optimized builds of emacs
2010-04-24 23:44 bug#6031: gcc 4.5 breaks optimized builds of emacs Elias Pipping
` (3 preceding siblings ...)
2010-04-26 20:17 ` bug#6031: Emacs 23.1 breaks with gcc 4.5 and -foptimize-sibling-calls Ulrich Mueller
@ 2010-04-27 11:26 ` Ulrich Mueller
2010-04-27 15:37 ` Chong Yidong
4 siblings, 1 reply; 15+ messages in thread
From: Ulrich Mueller @ 2010-04-27 11:26 UTC (permalink / raw
To: 6031
Looks like this is a GCC bug:
http://gcc.gnu.org/PR43904
http://gcc.gnu.org/PR43572
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#6031: gcc 4.5 breaks optimized builds of emacs
2010-04-27 11:26 ` bug#6031: gcc 4.5 breaks optimized builds of emacs Ulrich Mueller
@ 2010-04-27 15:37 ` Chong Yidong
0 siblings, 0 replies; 15+ messages in thread
From: Chong Yidong @ 2010-04-27 15:37 UTC (permalink / raw
To: Ulrich Mueller; +Cc: 6031
Ulrich Mueller <ulm@gentoo.org> writes:
> Looks like this is a GCC bug:
>
> http://gcc.gnu.org/PR43904
> http://gcc.gnu.org/PR43572
Thanks. I've added a PROBLEMS entry explaining this.
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2010-04-27 15:37 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-04-24 23:44 bug#6031: gcc 4.5 breaks optimized builds of emacs Elias Pipping
2010-04-25 3:07 ` Dan Nicolaescu
2010-04-25 11:12 ` Elias Pipping
2010-04-25 13:33 ` Eli Zaretskii
2010-04-25 14:56 ` Elias Pipping
2010-04-25 16:15 ` Eli Zaretskii
2010-04-26 22:41 ` Elias Pipping
2010-04-25 18:32 ` Chong Yidong
2010-04-26 15:40 ` Elias Pipping
2010-04-26 17:40 ` Eli Zaretskii
2010-04-26 22:12 ` Elias Pipping
2010-04-26 20:17 ` bug#6031: Emacs 23.1 breaks with gcc 4.5 and -foptimize-sibling-calls Ulrich Mueller
2010-04-26 21:09 ` Dan Nicolaescu
2010-04-27 11:26 ` bug#6031: gcc 4.5 breaks optimized builds of emacs Ulrich Mueller
2010-04-27 15:37 ` Chong Yidong
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.