* bug#8217: 23.3; Runtime segmentation fault when compiled with -O2 on GNU/Linux
@ 2011-03-10 8:34 Ulrich Mueller
2011-03-10 8:52 ` Andreas Schwab
2011-03-10 11:48 ` Eli Zaretskii
0 siblings, 2 replies; 10+ messages in thread
From: Ulrich Mueller @ 2011-03-10 8:34 UTC (permalink / raw)
To: 8217
[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 2267 bytes --]
Forwarding downstream bug: <https://bugs.gentoo.org/show_bug.cgi?id=358177>
Emacs 23.3 compiled with -O2 on x86_64-pc-linux-gnu immediately fails
with a segmentation fault at runtime. This is with GCC 4.5.2 (but it
also fails when compiled with GCC 4.4.5 or 4.3.5).
$ emacs -Q
Fatal error (11)Segmentation fault
The problem disappears when -fno-strict-aliasing is added to CFLAGS.
I've narrowed it down further:
- compile src/xterm.c with -O1,
compile the rest of the sources with -O2
=> Success
- compile src/xterm.c with -O2,
compile the rest of the sources with -O1
=> Failure
- compile src/xterm.c with -O2 -fno-strict-aliasing,
compile the rest of the sources with -O2
=> Success
- compile src/xterm.c with -O1 -fgcse -fstrict-aliasing,
compile the rest of the sources with -O1
=> Failure
GDB full backtrace is attached.
In GNU Emacs 23.3.1 (x86_64-pc-linux-gnu, X toolkit)
of 2011-03-10 on juno
Windowing system distributor `The X.Org Foundation', version 11.0.10904000
configured using `configure '--prefix=/usr' '--build=x86_64-pc-linux-gnu' '--host=x86_64-pc-linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib' '--libdir=/usr/lib64' '--program-suffix=-emacs-23' '--infodir=/usr/share/info/emacs-23' '--with-crt-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/../../../../lib64' '--with-gameuser=games' '--without-hesiod' '--without-kerberos' '--without-kerberos5' '--with-gpm' '--with-dbus' '--with-sound' '--with-x' '--without-ns' '--without-gconf' '--without-toolkit-scroll-bars' '--with-gif' '--with-jpeg' '--with-png' '--with-rsvg' '--with-tiff' '--with-xpm' '--with-xft' '--without-libotf' '--without-m17n-flt' '--with-x-toolkit=athena' 'build_alias=x86_64-pc-linux-gnu' 'host_alias=
x86_64-pc-linux-gnu' 'CC=gcc' 'CFLAGS=-march=core2 -ggdb -O2 -pipe' 'LDFLAGS=-Wl,-O1 -Wl,--as-needed' 'CPPFLAGS=''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: en_US.utf8
value of $XMODIFIERS: nil
locale-coding-system: utf-8-unix
default enable-multibyte-characters: t
[-- Attachment #2: gdb-backtrace --]
[-- Type: text/plain, Size: 18376 bytes --]
$ gdb emacs
GNU gdb (Gentoo 7.2 p1) 7.2
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://bugs.gentoo.org/>...
Reading symbols from /var/tmp/portage/app-editors/emacs-23.3/work/emacs-23.3/src/emacs...done.
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
DISPLAY = :0
TERM = dumb
Breakpoint 1 at 0x4d8a00: file emacs.c, line 430.
Temporary breakpoint 2 at 0x4f4b80: file sysdep.c, line 1129.
(gdb) run -Q
Starting program: /var/tmp/portage/app-editors/emacs-23.3/work/emacs-23.3/src/emacs -Q
[Thread debugging using libthread_db enabled]
Traceback (most recent call last):
File "/usr/share/gdb/auto-load/usr/lib64/gcc/x86_64-pc-linux-gnu/4.5.2/libstdc++.so.6.0.14-gdb.py", line 59, in <module>
from libstdcxx.v6.printers import register_libstdcxx_printers
ImportError: No module named libstdcxx.v6.printers
Program received signal SIGSEGV, Segmentation fault.
mark_byte_stack () at bytecode.c:292
292 mark_object (*obj);
(gdb) bt full
#0 mark_byte_stack () at bytecode.c:292
stack = 0x7fffffffd3c0
obj = 0x0
#1 0x00000000005384be in Fgarbage_collect () at alloc.c:5122
bind = <value optimized out>
catch = <value optimized out>
handler = <value optimized out>
stack_top_variable = 0 '\000'
i = <value optimized out>
message_p = 0
total = {12020450, 2, 2, 5563622, 140737488342492, 0,
140737322770432, 140737351957857}
t1 = {
tv_sec = 1299745224,
tv_usec = 486361
}
t2 = {
tv_sec = 12884901889,
tv_usec = 12020448
}
#2 0x0000000000589225 in Fbyte_code (bytestr=<value optimized out>,
vector=<value optimized out>, maxdepth=<value optimized out>)
at bytecode.c:529
v1 = <value optimized out>
count = 4
op = <value optimized out>
vectorp = 0x9d45e0
stack = {
pc = 0xa2f1a1 "\351\001\t@\020\201\177",
top = 0x7fffffffcc30,
bottom = 0x7fffffffcc30,
byte_string = 10306993,
byte_string_start = 0xa2efd7 "\306\307\310\311\312\313\314\315\316\317\320\321\322\323\324\325\326\327\310$\257\r\330\324\325\326\331\332$\324\325\326\327\330$\333BBB\334\324\325\326\331\335$\336BB\337\324\325\326\331\340$D\341\324\325\326\331\342$D\343\324\325\326\331\344$D\345\324\325\326\331\346$D\347\324\325\326\331\350$D\351\324\325\326\331\352$D\353\324\325\326\331\354$D\355\324\325\326\331\356$D\357\324\325\326\331\360$D\361\324\325\326\331\362$\324\325\326\327\361$E\363\324\325\326\331\364$\324\325\326\327\363$\365BBB\366\367\324\325\326\327\367$\370BB\371\324\325\326\327\371$\372BB\373\324\325\326\331\374$\375BB\376\324\325\326\327\376$\377BB\201H",
constants = 10307029,
next = 0x7fffffffd1e0
}
top = 0x7fffffffcc30
result = <value optimized out>
#3 0x000000000054dfdf in funcall_lambda (fun=10306941,
nargs=<value optimized out>, arg_vector=0x7fffffffced0) at eval.c:3220
val = <value optimized out>
syms_left = 11655570
next = <value optimized out>
i = <value optimized out>
optional = <value optimized out>
rest = <value optimized out>
#4 0x000000000054ffe0 in apply_lambda (fun=10306941,
args=<value optimized out>, eval_flag=1) at eval.c:3143
args_left = <value optimized out>
numargs = <value optimized out>
arg_vector = 0x7fffffffced0
i = <value optimized out>
tem = <value optimized out>
sa_must_free = 0
#5 0x000000000054d7e3 in Feval (form=<value optimized out>) at eval.c:2410
fun = <value optimized out>
val = <value optimized out>
original_fun = <value optimized out>
original_args = 11655570
funcar = <value optimized out>
backtrace = {
next = 0x7fffffffd300,
function = 0x7fffffffcfe8,
args = 0x7fffffffced0,
nargs = 0,
evalargs = 0 '\000',
debug_on_exit = 0 '\000'
}
#6 0x00000000005509ab in internal_lisp_condition_case (var=12365346,
bodyform=10332070, handlers=10332086) at eval.c:1437
val = <value optimized out>
c = {
tag = 11655570,
val = 11655570,
next = 0x7fffffffd700,
gcpro = 0x0,
jmp = {{
__jmpbuf = {140737488343456, -2504028783134923122, 10332024,
4611686018428436480, 4, 0, -2504028783080397170,
2504028068937836174},
__mask_was_saved = 0,
__saved_mask = {
__val = {140737351943634, 0, 0, 1, 0, 1, 140737354129736, 0,
0, 0, 0, 0, 140737354130592, 140737488343456,
140737488343480, 4294967297}
}
}},
backlist = 0x7fffffffd300,
handlerlist = 0x7fffffffd810,
lisp_eval_depth = 5,
pdlcount = 4,
poll_suppress_count = 1,
interrupt_input_blocked = 0,
byte_stack = 0x7fffffffd1e0
}
h = {
handler = 10332086,
var = 12365346,
chosen_clause = 4607182418800017408,
tag = 0x7fffffffd050,
next = 0x7fffffffd810
}
#7 0x0000000000587bfb in Fbyte_code (bytestr=<value optimized out>,
vector=<value optimized out>, maxdepth=<value optimized out>)
at bytecode.c:870
handlers = <value optimized out>
body = <value optimized out>
count = 4
op = <value optimized out>
vectorp = 0x9da788
stack = {
pc = 0xa9e722 "\207",
top = 0x7fffffffd1a0,
bottom = 0x7fffffffd1a0,
byte_string = 10331993,
byte_string_start = 0xa9e71e "\300\301\302\217\207",
constants = 10332029,
next = 0x7fffffffd3c0
}
top = 0x7fffffffd1a0
result = <value optimized out>
#8 0x000000000054dfdf in funcall_lambda (fun=10331941,
nargs=<value optimized out>, arg_vector=0x7fffffffd368) at eval.c:3220
val = <value optimized out>
syms_left = 11655570
next = <value optimized out>
i = <value optimized out>
optional = <value optimized out>
rest = <value optimized out>
#9 0x400000000054e333 in Ffuncall (nargs=1, args=0x7fffffffd360)
at eval.c:3088
fun = <value optimized out>
original_fun = 16949186
funcar = <value optimized out>
numargs = 0
lisp_numargs = <value optimized out>
val = <value optimized out>
backtrace = {
next = 0x7fffffffd4e0,
function = 0x7fffffffd360,
args = 0x7fffffffd368,
nargs = 0,
evalargs = 0 '\000',
debug_on_exit = 0 '\000'
}
internal_args = <value optimized out>
i = <value optimized out>
#10 0x0000000000588aad in Fbyte_code (bytestr=<value optimized out>,
vector=<value optimized out>, maxdepth=<value optimized out>)
at bytecode.c:680
count = 4
op = <value optimized out>
vectorp = 0x9ecd78
stack = {
pc = 0xa2aff7 "\210\324\325\326\217\210\327 \210\330\331\332\"Ûš\203V",
top = 0x7fffffffd360,
bottom = 0x0,
byte_string = 10407241,
byte_string_start = 0xa2afb8 "\b;\204\034",
constants = 10407277,
next = 0x7fffffffd580
}
top = 0x7fffffffd360
result = <value optimized out>
#11 0x000000000054dfdf in funcall_lambda (fun=10407189,
nargs=<value optimized out>, arg_vector=0x7fffffffd548) at eval.c:3220
val = <value optimized out>
syms_left = 11655570
next = <value optimized out>
i = <value optimized out>
optional = <value optimized out>
rest = <value optimized out>
#12 0x000000000054e333 in Ffuncall (nargs=1, args=0x7fffffffd540)
at eval.c:3088
fun = <value optimized out>
original_fun = 15841058
funcar = <value optimized out>
numargs = 0
lisp_numargs = <value optimized out>
val = <value optimized out>
backtrace = {
next = 0x7fffffffd670,
function = 0x7fffffffd540,
args = 0x7fffffffd548,
nargs = 0,
evalargs = 0 '\000',
debug_on_exit = 0 '\000'
}
internal_args = <value optimized out>
i = <value optimized out>
#13 0x0000000000588aad in Fbyte_code (bytestr=<value optimized out>,
vector=<value optimized out>, maxdepth=<value optimized out>)
at bytecode.c:680
count = 4
op = <value optimized out>
vectorp = 0x89e9c0
stack = {
pc = 0xa7e3c7 "\210Ň",
top = 0x7fffffffd540,
bottom = 0x7fffffffd540,
byte_string = 9038209,
byte_string_start = 0xa7e394 "\b\204\064",
constants = 9038261,
next = 0x7fffffffd8b0
}
top = 0x7fffffffd540
result = <value optimized out>
#14 0x000000000054db5f in Feval (form=<value optimized out>) at eval.c:2356
numargs = <value optimized out>
args_left = 11655570
i = 3
maxargs = 3
argvals = {9038209, 9038261, 16, 4308901940, 72057594051862583, 0,
72057594037927936, 15703072}
fun = <value optimized out>
val = <value optimized out>
original_fun = <value optimized out>
original_args = 9038198
funcar = <value optimized out>
backtrace = {
next = 0x7fffffffd9d0,
function = 0x7fffffffd698,
args = 0x7fffffffd630,
nargs = 3,
evalargs = 1 '\001',
debug_on_exit = 0 '\000'
}
#15 0x00000000005509ab in internal_lisp_condition_case (var=11722834,
bodyform=9038182, handlers=9038446) at eval.c:1437
val = <value optimized out>
c = {
tag = 11655570,
val = 11655570,
next = 0x7fffffffdcf0,
gcpro = 0x0,
jmp = {{
__jmpbuf = {140737488345168, -2504028783317375346, 9034440,
4611686018428436480, 4, 0, -2504028783023774066,
2504028068937836174},
__mask_was_saved = 0,
__saved_mask = {
__val = {140737488344992, 140737488344992, 2, 2, 5563603,
11168192, 5563636, 9037377, 15709841, 11655570, 11655666,
11870034, 11695824, 11655618, 11871032, 0}
}
}},
backlist = 0x7fffffffd9d0,
handlerlist = 0x7fffffffde00,
lisp_eval_depth = 2,
pdlcount = 4,
poll_suppress_count = 1,
interrupt_input_blocked = 0,
byte_stack = 0x7fffffffd8b0
}
h = {
handler = 9038446,
var = 11722834,
chosen_clause = 140737488345376,
tag = 0x7fffffffd700,
next = 0x7fffffffde00
}
#16 0x0000000000587bfb in Fbyte_code (bytestr=<value optimized out>,
vector=<value optimized out>, maxdepth=<value optimized out>)
at bytecode.c:870
handlers = <value optimized out>
body = <value optimized out>
count = 4
op = <value optimized out>
vectorp = 0x89dad8
stack = {
pc = 0xa7e6eb "\210\375\376!\210\377 \204#\002\201\213",
top = 0x7fffffffd850,
bottom = 0x7fffffffd850,
byte_string = 9034409,
byte_string_start = 0xa7e4d7 "\306 \020\307\021\n\023\307\024\310\311!\211\035\307=\204\064",
constants = 9034445,
next = 0x7fffffffda80
}
top = 0x7fffffffd850
result = <value optimized out>
#17 0x000000000054dfdf in funcall_lambda (fun=9034365,
nargs=<value optimized out>, arg_vector=0x7fffffffda38) at eval.c:3220
val = <value optimized out>
syms_left = 11655570
next = <value optimized out>
i = <value optimized out>
optional = <value optimized out>
rest = <value optimized out>
#18 0x000000000054e333 in Ffuncall (nargs=1, args=0x7fffffffda30)
at eval.c:3088
fun = <value optimized out>
original_fun = 13110386
funcar = <value optimized out>
numargs = 0
lisp_numargs = <value optimized out>
val = <value optimized out>
backtrace = {
next = 0x7fffffffdc60,
function = 0x7fffffffda30,
args = 0x7fffffffda38,
nargs = 0,
evalargs = 0 '\000',
debug_on_exit = 0 '\000'
}
internal_args = <value optimized out>
i = <value optimized out>
#19 0x0000000000588aad in Fbyte_code (bytestr=<value optimized out>,
vector=<value optimized out>, maxdepth=<value optimized out>)
at bytecode.c:680
count = 2
op = <value optimized out>
vectorp = 0x89c330
stack = {
pc = 0xa7f284 "\210*\340\341\342\"\210\343\321\344\"\211\036$;\203\251",
top = 0x7fffffffda30,
bottom = 0x7fffffffda30,
byte_string = 9028353,
byte_string_start = 0xa7f1f6 "\b\203\b",
constants = 9028389,
next = 0x0
}
top = 0x7fffffffda30
result = <value optimized out>
#20 0x000000000054dfdf in funcall_lambda (fun=9028309,
nargs=<value optimized out>, arg_vector=0x7fffffffdb70) at eval.c:3220
val = <value optimized out>
syms_left = 11655570
next = <value optimized out>
i = <value optimized out>
optional = <value optimized out>
rest = <value optimized out>
#21 0x000000000054ffe0 in apply_lambda (fun=9028309,
args=<value optimized out>, eval_flag=1) at eval.c:3143
args_left = <value optimized out>
numargs = <value optimized out>
arg_vector = 0x7fffffffdb70
i = <value optimized out>
tem = <value optimized out>
sa_must_free = 0
#22 0x000000000054d7e3 in Feval (form=<value optimized out>) at eval.c:2410
fun = <value optimized out>
val = <value optimized out>
original_fun = <value optimized out>
original_args = 11655570
funcar = <value optimized out>
backtrace = {
next = 0x0,
function = 0x7fffffffdc88,
args = 0x7fffffffdb70,
nargs = 0,
evalargs = 0 '\000',
debug_on_exit = 0 '\000'
}
#23 0x000000000054ca8f in internal_condition_case (
bfun=0x4dc7f0 <top_level_2>, handlers=11722834, hfun=0x4de4d0 <cmd_error>)
at eval.c:1492
val = <value optimized out>
c = {
tag = 11655570,
val = 11655570,
next = 0x7fffffffde60,
gcpro = 0x0,
jmp = {{
__jmpbuf = {0, 2504029303247971982, 12957984, 140737488347816,
1, 0, -2504028783218809202, 2504028058140124814},
__mask_was_saved = 0,
__saved_mask = {
__val = {140737353895936, 0, 4294967295, 140737488346536,
9089, 8405416, 0, 1, 0, 0, 140737351957857, 1, 0,
1869509994, 140737292555784, 1024}
}
}},
backlist = 0x0,
handlerlist = 0x0,
lisp_eval_depth = 0,
pdlcount = 2,
poll_suppress_count = 1,
interrupt_input_blocked = 0,
byte_stack = 0x0
}
h = {
handler = 11722834,
var = 11655570,
chosen_clause = 11655570,
tag = 0x7fffffffdcf0,
next = 0x0
}
#24 0x00000000004dd696 in top_level_1 () at keyboard.c:1379
No locals.
#25 0x000000000054c96a in internal_catch (tag=-16777216,
func=0x4dd630 <top_level_1>, arg=11655570) at eval.c:1228
c = {
tag = 11715650,
val = 11655570,
next = 0x0,
gcpro = 0x0,
jmp = {{
__jmpbuf = {0, 2504029303247971982, 12957984, 140737488347816,
1, 0, -2504028783269140850, 2504028058243409550},
__mask_was_saved = 0,
__saved_mask = {
__val = {0, 0, 0, 0, 0, 112, 11655570, 11935538, 11695824,
11655618, 11930648, 1, 5491910, 0, 100, 11935538}
}
}},
backlist = 0x0,
handlerlist = 0x0,
lisp_eval_depth = 0,
pdlcount = 2,
poll_suppress_count = 1,
interrupt_input_blocked = 0,
byte_stack = 0x0
}
#26 0x00000000004de6b9 in command_loop () at keyboard.c:1334
No locals.
#27 0x00000000004de76a in recursive_edit_1 () at keyboard.c:956
val = <value optimized out>
#28 0x00000000004de8a6 in Frecursive_edit () at keyboard.c:1018
buffer = 11655570
#29 0x00000000004da0c5 in main (argc=<value optimized out>,
argv=0x7fffffffe3e8) at emacs.c:1833
dummy = 256
stack_bottom_variable = 0 '\000'
do_initial_setlocale = <value optimized out>
skip_args = 0
rlim = {
rlim_cur = 8720000,
rlim_max = 18446744073709551615
}
no_loadup = 0
junk = 0x0
dname_arg = 0x0
Lisp Backtrace:
"setup-default-fontset" (0xffffced0)
"create-default-fontset" (0xffffd368)
"x-initialize-window-system" (0xffffd548)
"byte-code" (0xffffd630)
"command-line" (0xffffda38)
"normal-top-level" (0xffffdb70)
(gdb)
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#8217: 23.3; Runtime segmentation fault when compiled with -O2 on GNU/Linux
2011-03-10 8:34 bug#8217: 23.3; Runtime segmentation fault when compiled with -O2 on GNU/Linux Ulrich Mueller
@ 2011-03-10 8:52 ` Andreas Schwab
[not found] ` <19832.41051.618372.463060@a1i15.kph.uni-mainz.de>
2011-03-10 11:48 ` Eli Zaretskii
1 sibling, 1 reply; 10+ messages in thread
From: Andreas Schwab @ 2011-03-10 8:52 UTC (permalink / raw)
To: Ulrich Mueller; +Cc: 8217
Ulrich Mueller <ulm@gentoo.org> writes:
> Forwarding downstream bug: <https://bugs.gentoo.org/show_bug.cgi?id=358177>
>
> Emacs 23.3 compiled with -O2 on x86_64-pc-linux-gnu immediately fails
> with a segmentation fault at runtime. This is with GCC 4.5.2 (but it
> also fails when compiled with GCC 4.4.5 or 4.3.5).
>
> $ emacs -Q
> Fatal error (11)Segmentation fault
>
> The problem disappears when -fno-strict-aliasing is added to CFLAGS.
Try compiling with -Wstrict-aliasing.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#8217: 23.3; Runtime segmentation fault when compiled with -O2 on GNU/Linux
2011-03-10 8:34 bug#8217: 23.3; Runtime segmentation fault when compiled with -O2 on GNU/Linux Ulrich Mueller
2011-03-10 8:52 ` Andreas Schwab
@ 2011-03-10 11:48 ` Eli Zaretskii
2011-03-10 12:08 ` Ulrich Mueller
1 sibling, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2011-03-10 11:48 UTC (permalink / raw)
To: Ulrich Mueller; +Cc: 8217
> Date: Thu, 10 Mar 2011 09:34:46 +0100
> From: Ulrich Mueller <ulm@gentoo.org>
> Cc:
>
> Forwarding downstream bug: <https://bugs.gentoo.org/show_bug.cgi?id=358177>
>
> Emacs 23.3 compiled with -O2 on x86_64-pc-linux-gnu immediately fails
> with a segmentation fault at runtime. This is with GCC 4.5.2 (but it
> also fails when compiled with GCC 4.4.5 or 4.3.5).
>
> $ emacs -Q
> Fatal error (11)Segmentation fault
FWIW, I cannot reproduce this on this system:
Linux fencepost 2.6.32-313-ec2 #26-Ubuntu SMP Fri Feb 11 22:34:31 UTC 2011 x86_64 GNU/Linux
with this version of GCC:
gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3
and configured slightly differently, as follows:
x86_64-unknown-linux-gnu --with-gif=no --with-tiff=no
with GTK+ Version 2.20.1 as the toolkit.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#8217: 23.3; Runtime segmentation fault when compiled with -O2 on GNU/Linux
2011-03-10 11:48 ` Eli Zaretskii
@ 2011-03-10 12:08 ` Ulrich Mueller
2011-03-24 16:26 ` Chong Yidong
2016-08-05 1:28 ` npostavs
0 siblings, 2 replies; 10+ messages in thread
From: Ulrich Mueller @ 2011-03-10 12:08 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 8217
>>>>> On Thu, 10 Mar 2011, Eli Zaretskii wrote:
> FWIW, I cannot reproduce this on this system:
> Linux fencepost 2.6.32-313-ec2 #26-Ubuntu SMP Fri Feb 11 22:34:31 UTC 2011 x86_64 GNU/Linux
> [...]
> with GTK+ Version 2.20.1 as the toolkit.
I confirm that it doesn't fail for me if I configure --with-toolkit=gtk.
The segfault occurs with the --with-toolkit=athena configure option.
Ulrich
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#8217: 23.3; Runtime segmentation fault when compiled with -O2 on GNU/Linux
[not found] ` <19832.49227.947125.153989@a1i15.kph.uni-mainz.de>
@ 2011-03-10 18:39 ` Glenn Morris
0 siblings, 0 replies; 10+ messages in thread
From: Glenn Morris @ 2011-03-10 18:39 UTC (permalink / raw)
To: Ulrich Mueller; +Cc: 8217
Ulrich Mueller wrote:
> [Resending; looks like my original reply was lost.]
This is a moderated list and your messages were large and were waiting
for review, please be patient. Looks like someone accepted the second
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8217#17
and then discarded the first, since two copies were not necessary.
For capacity reasons, lists.gnu.org has some unspecified hard limit,
independent of list moderation, see eg
http://lists.gnu.org/archive/html/savannah-hackers/2011-03/msg00004.html
so it is quite likely your messages will never appear on bug-gnu-emacs.
I do encourage people to send large logs as compressed attachments.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#8217: 23.3; Runtime segmentation fault when compiled with -O2 on GNU/Linux
2011-03-10 12:08 ` Ulrich Mueller
@ 2011-03-24 16:26 ` Chong Yidong
2011-03-25 1:17 ` Stefan Monnier
2016-08-05 1:28 ` npostavs
1 sibling, 1 reply; 10+ messages in thread
From: Chong Yidong @ 2011-03-24 16:26 UTC (permalink / raw)
To: Ulrich Mueller; +Cc: 8217
Ulrich Mueller <ulm@gentoo.org> writes:
>> FWIW, I cannot reproduce this on this system:
>
>> Linux fencepost 2.6.32-313-ec2 #26-Ubuntu SMP Fri Feb 11 22:34:31
>> UTC 2011 x86_64 GNU/Linux
>
>> [...]
>
>> with GTK+ Version 2.20.1 as the toolkit.
>
> I confirm that it doesn't fail for me if I configure --with-toolkit=gtk.
> The segfault occurs with the --with-toolkit=athena configure option.
I think this has to do with the messy way we handle scroll bars, which
are currently stored as Lisp objects and recast into scroll_bar
structures when used.
By the way, I notice that x_scroll_bar_create has
struct scroll_bar *bar
= ALLOCATE_PSEUDOVECTOR (struct scroll_bar, x_window, PVEC_OTHER);
I don't know if the former is correct (it was introduced back in
revision 82084 by Stefan), but it means the SCROLL_BAR_VEC_SIZE macro
defined in xterm.h is unused, which looks odd. In comparison, w32term.c
has
struct scroll_bar *bar
= XSCROLL_BAR (Fmake_vector (make_number (SCROLL_BAR_VEC_SIZE), Qnil));
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#8217: 23.3; Runtime segmentation fault when compiled with -O2 on GNU/Linux
2011-03-24 16:26 ` Chong Yidong
@ 2011-03-25 1:17 ` Stefan Monnier
0 siblings, 0 replies; 10+ messages in thread
From: Stefan Monnier @ 2011-03-25 1:17 UTC (permalink / raw)
To: Chong Yidong; +Cc: Ulrich Mueller, 8217
> By the way, I notice that x_scroll_bar_create has
> struct scroll_bar *bar
> = ALLOCATE_PSEUDOVECTOR (struct scroll_bar, x_window, PVEC_OTHER);
> I don't know if the former is correct (it was introduced back in
> revision 82084 by Stefan),
It should be. It should allocate a vector large enough for `struct
scroll_bar' and with all fields up to x_window of type Lisp_Object and
traceable by the GC.
> but it means the SCROLL_BAR_VEC_SIZE macro defined in xterm.h is
> unused, which looks odd.
Looks like a left over I failed to remove.
> In comparison, w32term.c has
> struct scroll_bar *bar
> = XSCROLL_BAR (Fmake_vector (make_number (SCROLL_BAR_VEC_SIZE), Qnil));
Looks like I also failed to apply my change to w32term.c.
Stefan
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#8217: 23.3; Runtime segmentation fault when compiled with -O2 on GNU/Linux
2011-03-10 12:08 ` Ulrich Mueller
2011-03-24 16:26 ` Chong Yidong
@ 2016-08-05 1:28 ` npostavs
2016-08-06 13:29 ` Ulrich Mueller
1 sibling, 1 reply; 10+ messages in thread
From: npostavs @ 2016-08-05 1:28 UTC (permalink / raw)
To: Ulrich Mueller; +Cc: 8217
Ulrich Mueller <ulm@gentoo.org> writes:
>>>>>> On Thu, 10 Mar 2011, Eli Zaretskii wrote:
>
>> FWIW, I cannot reproduce this on this system:
>
>> Linux fencepost 2.6.32-313-ec2 #26-Ubuntu SMP Fri Feb 11 22:34:31 UTC 2011 x86_64 GNU/Linux
>
>> [...]
>
>> with GTK+ Version 2.20.1 as the toolkit.
>
> I confirm that it doesn't fail for me if I configure --with-toolkit=gtk.
> The segfault occurs with the --with-toolkit=athena configure option.
I guess this is fixed by now? I usually build --with-toolkit=lucid
(which I read in configure.ac is a synonym for athena), and I haven't
hit this.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#8217: 23.3; Runtime segmentation fault when compiled with -O2 on GNU/Linux
2016-08-05 1:28 ` npostavs
@ 2016-08-06 13:29 ` Ulrich Mueller
2016-08-06 13:34 ` npostavs
0 siblings, 1 reply; 10+ messages in thread
From: Ulrich Mueller @ 2016-08-06 13:29 UTC (permalink / raw)
To: npostavs; +Cc: 8217
>>>>> On Thu, 04 Aug 2016, npostavs wrote:
> I guess this is fixed by now? I usually build --with-toolkit=lucid
> (which I read in configure.ac is a synonym for athena), and I
> haven't hit this.
Looking through Gentoo ebuild history, I find that the workaround of
adding -fno-strict-aliasing to CFLAGS wasn't present for version 24.1,
and there never were any bugs reported to us. This seems to indicate
that the problem had disappeared already in early Emacs 24 versions.
However, I also cannot reproduce this any more with Emacs 23.4 and
GCC 5.4.0 (nor with GCC 4.9.3). So it may well be that this issue
wasn't with Emacs but with GCC.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#8217: 23.3; Runtime segmentation fault when compiled with -O2 on GNU/Linux
2016-08-06 13:29 ` Ulrich Mueller
@ 2016-08-06 13:34 ` npostavs
0 siblings, 0 replies; 10+ messages in thread
From: npostavs @ 2016-08-06 13:34 UTC (permalink / raw)
To: Ulrich Mueller; +Cc: 8217
tags 8217 unreproducible
close 8217
quit
Ulrich Mueller <ulm@gentoo.org> writes:
>>>>>> On Thu, 04 Aug 2016, npostavs wrote:
>
>> I guess this is fixed by now? I usually build --with-toolkit=lucid
>> (which I read in configure.ac is a synonym for athena), and I
>> haven't hit this.
>
> Looking through Gentoo ebuild history, I find that the workaround of
> adding -fno-strict-aliasing to CFLAGS wasn't present for version 24.1,
> and there never were any bugs reported to us. This seems to indicate
> that the problem had disappeared already in early Emacs 24 versions.
>
> However, I also cannot reproduce this any more with Emacs 23.4 and
> GCC 5.4.0 (nor with GCC 4.9.3). So it may well be that this issue
> wasn't with Emacs but with GCC.
Okay, closing as unreproducible.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2016-08-06 13:34 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-03-10 8:34 bug#8217: 23.3; Runtime segmentation fault when compiled with -O2 on GNU/Linux Ulrich Mueller
2011-03-10 8:52 ` Andreas Schwab
[not found] ` <19832.41051.618372.463060@a1i15.kph.uni-mainz.de>
[not found] ` <19832.49227.947125.153989@a1i15.kph.uni-mainz.de>
2011-03-10 18:39 ` Glenn Morris
2011-03-10 11:48 ` Eli Zaretskii
2011-03-10 12:08 ` Ulrich Mueller
2011-03-24 16:26 ` Chong Yidong
2011-03-25 1:17 ` Stefan Monnier
2016-08-05 1:28 ` npostavs
2016-08-06 13:29 ` Ulrich Mueller
2016-08-06 13:34 ` npostavs
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).