bug#8217: 23.3; Runtime segmentation fault when compiled with -O2 on GNU/Linux

unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed

* 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

[parent not found: <19832.41051.618372.463060@a1i15.kph.uni-mainz.de>]

[parent not found: <19832.49227.947125.153989@a1i15.kph.uni-mainz.de>]

* 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  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
  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).