bug#30855: 25.3; temacs fails with bus error during garbage collection

bug#30855: 25.3; temacs fails with bus error during garbage collection

[Ulrich Mueller]

Forwarding Gentoo bug: https://bugs.gentoo.org/647238

When building Emacs 25.3 on a sparc64 system with 32 bit userland
(Linux 4.14.14 sparc64, gcc-6.4.0, glibc-2.25-r10), temacs fails with
a bus error:

Loading loadup.el (source)...
Using load-path (/var/tmp/portage/app-editors/emacs-25.3-r3/work/emacs-25.3/lisp /var/tmp/portage/app-editors/emacs-25.3-r3/work/emacs-25.3/lisp/emacs-lisp /var/tmp/portage/app-editors/emacs-25.3-r3/work/emacs-25.3/lisp/language /var/tmp/portage/app-editors/emacs-25.3-r3/work/emacs-25.3/lisp/international /var/tmp/portage/app-editors/emacs-25.3-r3/work/emacs-25.3/lisp/textmodes /var/tmp/portage/app-editors/emacs-25.3-r3/work/emacs-25.3/lisp/vc)
Loading emacs-lisp/byte-run...
Loading emacs-lisp/backquote...
Loading subr...
Loading version...
make[1]: *** [Makefile:737: bootstrap-emacs] Bus error
make[1]: Leaving directory '/var/tmp/portage/app-editors/emacs-25.3-r3/work/emacs-25.3/src'
make: *** [Makefile:398: src] Error 2

See backtrace and configure options below. Note that Emacs was
configured with the --with-wide-int option, so Lisp_Object has a size
of 8 bytes, whereas pointers (and GC_POINTER_ALIGNMENT) are 4 bytes.
Especially, pp = 0xffffaefc is not aligned at an 8 byte boundary.


Program received signal SIGBUS, Bus error.
0x0021c638 in mark_memory (start=0xffffaef8, end=0xffffc870) at alloc.c:4895
4895          mark_maybe_object (*(Lisp_Object *) pp);
(gdb) bt full
#0  0x0021c638 in mark_memory (start=0xffffaef8, end=0xffffc870) at alloc.c:4895
        pp = 0xffffaefc ""
#1  0x0021c69c in mark_stack (end=0xffffaef8) at alloc.c:5038
No locals.
#2  0x0021e410 in garbage_collect_1 (end=0xffffaef8) at alloc.c:5760
        nextb = 0x0
        stack_top_variable = 0 '\000'
        i = 527
        message_p = false
        count = 23
        start = {tv_sec = 1521456162, tv_nsec = 586770363}
        retval = 0
        tot_before = 0
        total = {0, 203128, 4611686018427387936, 4611686018427387904, 0, 6072456, 42949672965, 137445489480, 210104, -6917529027635009400}
#3  0x0021f0b4 in Fgarbage_collect () at alloc.c:5983
        end = 0xffffaef8
#4  0x00258180 in eval_sub (form=-4611686018420189376) at eval.c:2169
        i = 0
        maxargs = 0
        args_left = 0
        numargs = 4611686018427387904
        fun = -6917529027635009400
        val = -6917529027634378352
        original_fun = 210104
        original_args = 0
        funcar = 0
        count = 22
        argvals = {-9223372036847521760, 0, 21072, 4611686018433923912, 695672, 2987888495278920, -6917529027634378352, -4611686018420189328}
#5  0x00251930 in Fprogn (body=-4611686018420189328) at eval.c:431
        val = 0
#6  0x0025b92c in funcall_lambda (fun=-4611686018420189296, nargs=1, arg_vector=0xffffb5c0) at eval.c:2922
        val = 0
        syms_left = 0
        next = 695672
        lexenv = 0
        count = 21
        i = 1
        optional = false
        rest = false
#7  0x0025aa7c in Ffuncall (nargs=2, args=0xffffb5b8) at eval.c:2760
        fun = -4611686018420189296
        original_fun = -4611686018420189296
        funcar = 26016
        numargs = 1
        lisp_numargs = 0
        val = 4
        internal_args = 0x6e724c
        count = 20
#8  0x00259088 in funcall_nil (nargs=2, args=0xffffb5b8) at eval.c:2338
No locals.
#9  0x00259738 in run_hook_with_args (nargs=2, args=0xffffb5b8, funcall=0x25906c <funcall_nil>) at eval.c:2515
        global_vals = 0
        sym = 637976
        val = -4611686018420189248
        ret = 0
#10 0x00259150 in Frun_hook_with_args (nargs=2, args=0xffffb5b8) at eval.c:2380
No locals.
#11 0x0025a318 in Ffuncall (nargs=3, args=0xffffb5b0) at eval.c:2679
        fun = -6917529027635003944
        original_fun = 35280
        funcar = 0
        numargs = 2
        lisp_numargs = 4156751872
        val = 0
        internal_args = 0x63bb48 <lispsym>
        count = 19
#12 0x002c2a64 in exec_byte_code (bytestr=-9223372036847584608, vector=-6917529027633902504, maxdepth=4611686018427387914, args_template=4611686018427388161, nargs=1, args=0xffffbbe8) at bytecode.c:880
        targets = {0x2c74c8 <exec_byte_code+23484>, 0x2c7588 <exec_byte_code+23676>, 0x2c7590 <exec_byte_code+23684>, 0x2c7598 <exec_byte_code+23692>, 0x2c75a0 <exec_byte_code+23700>, 0x2c75a0 <exec_byte_code+23700>, 0x2c7608 <exec_byte_code+23804>, 
          0x2c7680 <exec_byte_code+23924>, 0x2c1f74 <exec_byte_code+1640>, 0x2c1f7c <exec_byte_code+1648>, 0x2c1f84 <exec_byte_code+1656>, 0x2c1f8c <exec_byte_code+1664>, 0x2c1f94 <exec_byte_code+1672>, 0x2c1f94 <exec_byte_code+1672>, 
          0x2c1fa8 <exec_byte_code+1692>, 0x2c1f28 <exec_byte_code+1564>, 0x2c265c <exec_byte_code+3408>, 0x2c2664 <exec_byte_code+3416>, 0x2c266c <exec_byte_code+3424>, 0x2c2674 <exec_byte_code+3432>, 0x2c267c <exec_byte_code+3440>, 
          0x2c267c <exec_byte_code+3440>, 0x2c26d4 <exec_byte_code+3528>, 0x2c2690 <exec_byte_code+3460>, 0x2c2908 <exec_byte_code+4092>, 0x2c2910 <exec_byte_code+4100>, 0x2c2918 <exec_byte_code+4108>, 0x2c2920 <exec_byte_code+4116>, 
          0x2c2928 <exec_byte_code+4124>, 0x2c2928 <exec_byte_code+4124>, 0x2c28a4 <exec_byte_code+3992>, 0x2c28c4 <exec_byte_code+4024>, 0x2c2a08 <exec_byte_code+4348>, 0x2c2a10 <exec_byte_code+4356>, 0x2c2a18 <exec_byte_code+4364>, 
          0x2c2a20 <exec_byte_code+4372>, 0x2c2a28 <exec_byte_code+4380>, 0x2c2a28 <exec_byte_code+4380>, 0x2c29a4 <exec_byte_code+4248>, 0x2c29c4 <exec_byte_code+4280>, 0x2c2b0c <exec_byte_code+4608>, 0x2c2b14 <exec_byte_code+4616>, 
          0x2c2b1c <exec_byte_code+4624>, 0x2c2b24 <exec_byte_code+4632>, 0x2c2b2c <exec_byte_code+4640>, 0x2c2b2c <exec_byte_code+4640>, 0x2c2aa8 <exec_byte_code+4508>, 0x2c2ac8 <exec_byte_code+4540>, 0x2c43d4 <exec_byte_code+10952>, 
          0x2c4270 <exec_byte_code+10596>, 0x2c4264 <exec_byte_code+10584>, 0x2c74c8 <exec_byte_code+23484>, 0x2c74c8 <exec_byte_code+23484>, 0x2c74c8 <exec_byte_code+23484>, 0x2c74c8 <exec_byte_code+23484>, 0x2c74c8 <exec_byte_code+23484>, 
          0x2c4690 <exec_byte_code+11652>, 0x2c47dc <exec_byte_code+11984>, 0x2c4870 <exec_byte_code+12132>, 0x2c4904 <exec_byte_code+12280>, 0x2c499c <exec_byte_code+12432>, 0x2c243c <exec_byte_code+2864>, 0x2c24e4 <exec_byte_code+3032>, 
          0x2c4a64 <exec_byte_code+12632>, 0x2c2338 <exec_byte_code+2604>, 0x2c2558 <exec_byte_code+3148>, 0x2c4b04 <exec_byte_code+12792>, 0x2c4b78 <exec_byte_code+12908>, 0x2c4bd4 <exec_byte_code+13000>, 0x2c4c48 <exec_byte_code+13116>, 
          0x2c4ca8 <exec_byte_code+13212>, 0x2c4d94 <exec_byte_code+13448>, 0x2c4df0 <exec_byte_code+13540>, 0x2c4e64 <exec_byte_code+13656>, 0x2c4ef0 <exec_byte_code+13796>, 0x2c4f4c <exec_byte_code+13888>, 0x2c4fa8 <exec_byte_code+13980>, 
          0x2c501c <exec_byte_code+14096>, 0x2c5090 <exec_byte_code+14212>, 0x2c5104 <exec_byte_code+14328>, 0x2c5190 <exec_byte_code+14468>, 0x2c51f0 <exec_byte_code+14564>, 0x2c5250 <exec_byte_code+14660>, 0x2c533c <exec_byte_code+14896>, 
          0x2c5404 <exec_byte_code+15096>, 0x2c54cc <exec_byte_code+15296>, 0x2c584c <exec_byte_code+16192>, 0x2c58c4 <exec_byte_code+16312>, 0x2c593c <exec_byte_code+16432>, 0x2c59b4 <exec_byte_code+16552>, 0x2c5a2c <exec_byte_code+16672>, 
          0x2c5a8c <exec_byte_code+16768>, 0x2c5b58 <exec_byte_code+16972>, 0x2c5bb8 <exec_byte_code+17068>, 0x2c5c18 <exec_byte_code+17164>, 0x2c5c78 <exec_byte_code+17260>, 0x2c5dac <exec_byte_code+17568>, 0x2c4080 <exec_byte_code+10100>, 
          0x2c5e2c <exec_byte_code+17696>, 0x2c5e88 <exec_byte_code+17788>, 0x2c5f68 <exec_byte_code+18012>, 0x2c5fe8 <exec_byte_code+18140>, 0x2c6068 <exec_byte_code+18268>, 0x2c60c4 <exec_byte_code+18360>, 0x2c6124 <exec_byte_code+18456>, 
          0x2c6184 <exec_byte_code+18552>, 0x2c6200 <exec_byte_code+18676>, 0x2c74c8 <exec_byte_code+23484>, 0x2c6278 <exec_byte_code+18796>, 0x2c62d0 <exec_byte_code+18884>, 0x2c6328 <exec_byte_code+18972>, 0x2c6380 <exec_byte_code+19060>, 
          0x2c63d8 <exec_byte_code+19148>, 0x2c6430 <exec_byte_code+19236>, 0x2c4080 <exec_byte_code+10100>, 0x2c74c8 <exec_byte_code+23484>, 0x2c648c <exec_byte_code+19328>, 0x2c6504 <exec_byte_code+19448>, 0x2c6560 <exec_byte_code+19540>, 
          0x2c65bc <exec_byte_code+19632>, 0x2c6630 <exec_byte_code+19748>, 0x2c66a4 <exec_byte_code+19864>, 0x2c6700 <exec_byte_code+19956>, 0x2c68bc <exec_byte_code+20400>, 0x2c6930 <exec_byte_code+20516>, 0x2c69a4 <exec_byte_code+20632>, 
          0x2c6a18 <exec_byte_code+20748>, 0x2c6a70 <exec_byte_code+20836>, 0x2c74c8 <exec_byte_code+23484>, 0x2c3f94 <exec_byte_code+9864>, 0x2c2c04 <exec_byte_code+4856>, 0x2c20f8 <exec_byte_code+2028>, 0x2c2dfc <exec_byte_code+5360>, 
          0x2c303c <exec_byte_code+5936>, 0x2c327c <exec_byte_code+6512>, 0x2c3efc <exec_byte_code+9712>, 0x2c3f54 <exec_byte_code+9800>, 0x2c284c <exec_byte_code+3904>, 0x2c4024 <exec_byte_code+10008>, 0x2c40bc <exec_byte_code+10160>, 
          0x2c4188 <exec_byte_code+10364>, 0x2c41e4 <exec_byte_code+10456>, 0x2c4424 <exec_byte_code+11032>, 0x2c44d8 <exec_byte_code+11212>, 0x2c4564 <exec_byte_code+11352>, 0x2c45ec <exec_byte_code+11488>, 0x2c2ba8 <exec_byte_code+4764>, 
          0x2c6acc <exec_byte_code+20928>, 0x2c6b58 <exec_byte_code+21068>, 0x2c6bb4 <exec_byte_code+21160>, 0x2c6c10 <exec_byte_code+21252>, 0x2c6c6c <exec_byte_code+21344>, 0x2c6cc8 <exec_byte_code+21436>, 0x2c6d3c <exec_byte_code+21552>, 
          0x2c6db0 <exec_byte_code+21668>, 0x2c6e24 <exec_byte_code+21784>, 0x2c6e98 <exec_byte_code+21900>, 0x2c7054 <exec_byte_code+22344>, 0x2c70c8 <exec_byte_code+22460>, 0x2c713c <exec_byte_code+22576>, 0x2c7198 <exec_byte_code+22668>, 
          0x2c720c <exec_byte_code+22784>, 0x2c7280 <exec_byte_code+22900>, 0x2c72dc <exec_byte_code+22992>, 0x2c7338 <exec_byte_code+23084>, 0x2c5cd8 <exec_byte_code+17356>, 0x2c5d38 <exec_byte_code+17452>, 0x2c7398 <exec_byte_code+23180>, 
          0x2c7430 <exec_byte_code+23332>, 0x2c74c8 <exec_byte_code+23484>, 0x2c34bc <exec_byte_code+7088>, 0x2c3684 <exec_byte_code+7544>, 0x2c38a0 <exec_byte_code+8084>, 0x2c3abc <exec_byte_code+8624>, 0x2c3cdc <exec_byte_code+9168>, 
          0x2c4d08 <exec_byte_code+13308>, 0x2c52b0 <exec_byte_code+14756>, 0x2c5edc <exec_byte_code+17872>, 0x2c771c <exec_byte_code+24080>, 0x2c7790 <exec_byte_code+24196>, 0x2c74c8 <exec_byte_code+23484>, 0x2c74c8 <exec_byte_code+23484>, 
          0x2c7828 <exec_byte_code+24348>, 0x2c74c8 <exec_byte_code+23484>, 0x2c74c8 <exec_byte_code+23484>, 0x2c74c8 <exec_byte_code+23484>, 0x2c74c8 <exec_byte_code+23484>, 0x2c74c8 <exec_byte_code+23484>, 0x2c74c8 <exec_byte_code+23484>, 
          0x2c74c8 <exec_byte_code+23484>, 0x2c74c8 <exec_byte_code+23484>, 0x2c74c8 <exec_byte_code+23484>, 0x2c78d4 <exec_byte_code+24520> <repeats 64 times>}
        count = 19
        op = 2
        vectorp = 0x6d8c60
        stack = {pc = 0x6da388 "\207", byte_string = -9223372036847584608, byte_string_start = 0x6da2fc "\b\211\203+", next = 0x0}
        top = 0xffffb5b0
        result = -6917529027633902280
        type = CATCHER
#13 0x0025b3fc in funcall_lambda (fun=-6917529027633902280, nargs=1, arg_vector=0xffffbbe0) at eval.c:2863
        size = 5
        val = 0
        syms_left = 4611686018427388161
        next = -6917529027633902280
        lexenv = 14
        count = 19
        i = 7198352
        optional = 140
        rest = false
#14 0x0025a8ec in Ffuncall (nargs=2, args=0xffffbbd8) at eval.c:2748
        fun = -6917529027633902280
        original_fun = 15168
        funcar = 15168
        numargs = 1
        lisp_numargs = 15168
        val = 0
        internal_args = 0xf4bdf7
        count = 18
#15 0x002599a0 in call1 (fn=15168, arg1=-9223372036847542432) at eval.c:2558
No locals.
#16 0x0029d014 in Fload (file=-9223372036847542496, noerror=0, nomessage=0, nosuffix=0, must_suffix=0) at lread.c:1349
        stream = 0x653400
        fd = 5
        fd_index = 18
        count = 18
        found = -9223372036847542432
        efound = -9223372036847542432
        hist_file_name = -9223372036847542432
        newer = false
        compiled = true
        handler = 0
        safe_p = true
        fmode = 0x3653b0 "r"
        version = 23
#17 0x00258318 in eval_sub (form=-4611686018420189232) at eval.c:2186
        i = 5
        maxargs = 5
        args_left = 0
        numargs = 4611686018427387905
        fun = -6917529027635000192
        val = 16
        original_fun = 27120
        original_args = -4611686018420191232
        funcar = 0
        count = 17
        argvals = {-9223372036847542496, 0, 0, 0, 0, 6536008, 33840, 21072}
#18 0x0029f4bc in readevalloop (readcharfun=21072, stream=0x653a00, sourcename=-9223372036847975664, printflag=false, unibyte=0, readfun=0, start=0, end=0) at lread.c:1927
        count1 = 17
        c = 40
        val = -4611686018420189232
        count = 13
        b = 0x0
        continue_reading_p = true
        lex_bound = 0
        whole_buffer = false
        first_sexp = false
        macroexpand = 0
#19 0x0029ce50 in Fload (file=-9223372036847975792, noerror=0, nomessage=0, nosuffix=0, must_suffix=0) at lread.c:1335
        stream = 0x653a00
        fd = 4
        fd_index = 5
        count = 5
        found = -9223372036847975696
        efound = 0
        hist_file_name = -9223372036847975664
        newer = false
        compiled = false
        handler = 0
        safe_p = true
        fmode = 0x3653b0 "r"
        version = 0
#20 0x00258318 in eval_sub (form=-4611686018420484784) at eval.c:2186
        i = 5
        maxargs = 5
        args_left = 0
        numargs = 4611686018427387905
        fun = -6917529027635000192
        val = 4294967295
        original_fun = 27120
        original_args = -4611686018420484800
        funcar = 0
        count = 4
        argvals = {-9223372036847975792, 0, 0, 0, 0, 0, 24624, 6560632}
#21 0x00257298 in Feval (form=-4611686018420484784, lexical=0) at eval.c:1994
        count = 3
#22 0x0015dda4 in top_level_2 () at keyboard.c:1121
No locals.
#23 0x00254bdc in internal_condition_case (bfun=0x15dd68 <top_level_2>, handlers=16128, hfun=0x15d370 <cmd_error>) at eval.c:1315
        val = 6642432
        c = 0x655a00
#24 0x0015de30 in top_level_1 (ignore=0) at keyboard.c:1129
No locals.
#25 0x00254064 in internal_catch (tag=40128, func=0x15ddbc <top_level_1>, arg=0) at eval.c:1080
        val = -62775235462328
        c = 0x655b00
#26 0x0015dc1c in command_loop () at keyboard.c:1090
No locals.
#27 0x0015cbd0 in recursive_edit_1 () at keyboard.c:697
        count = 1
        val = 0
#28 0x0015cef0 in Frecursive_edit () at keyboard.c:768
        count = 0
        buffer = 0
#29 0x001597b8 in main (argc=5, argv=0xffffc984) at emacs.c:1629
        dummy = 0
        stack_bottom_variable = -9 '\367'
        do_initial_setlocale = true
        dumping = true
        skip_args = 3
        rlim = {rlim_cur = 8388608, rlim_max = 18446744073709551615}
        no_loadup = false
        junk = 0x0
        dname_arg = 0x0
        ch_to_dir = 0x0
        original_pwd = 0x0


Configure options:
./configure --prefix=/usr --build=sparc-unknown-linux-gnu
--host=sparc-unknown-linux-gnu --mandir=/usr/share/man
--infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
--localstatedir=/var/lib --disable-dependency-tracking
--disable-silent-rules --docdir=/usr/share/doc/emacs-25.3-r3
--htmldir=/usr/share/doc/emacs-25.3-r3/html --libdir=/usr/lib
--program-suffix=-emacs-25 --infodir=/usr/share/info/emacs-25
--localstatedir=/var
--enable-locallisppath=/etc/emacs:/usr/share/emacs/site-lisp
--with-gameuser=:gamestat --without-compress-install
--with-file-notification=no --disable-acl --with-dbus
--without-modules --with-gpm --without-hesiod --with-kerberos
--with-kerberos5 --with-xml2 --without-selinux --without-gnutls
--with-wide-int --with-zlib --with-sound=oss --with-x --without-ns
--without-gconf --with-gsettings --without-toolkit-scroll-bars
--with-gif --without-jpeg --with-png --without-rsvg --with-tiff
--without-xpm --without-imagemagick --with-xft --without-cairo
--without-libotf --without-m17n-flt --with-x-toolkit=motif

bug#30855: 25.3; temacs fails with bus error during garbage collection

[Eli Zaretskii]

> Date: Mon, 19 Mar 2018 16:23:34 +0100
> From: Ulrich Mueller <ulm@gentoo.org>
> Cc: Rolf Eike Beer <gentoo-bug@opensource.sf-tec.de>
> 
> Forwarding Gentoo bug: https://bugs.gentoo.org/647238
> 
> When building Emacs 25.3 on a sparc64 system with 32 bit userland
> (Linux 4.14.14 sparc64, gcc-6.4.0, glibc-2.25-r10), temacs fails with
> a bus error:

Thanks.  We are not planning any further v25.x releases, so if this
problem doesn't happen with the latest pretest of Emacs 26.1, we will
consider it resolved.

bug#30855: 25.3; temacs fails with bus error during garbage collection

[Ulrich Mueller]

>>>>> On Mon, 19 Mar 2018, Eli Zaretskii wrote:

> Thanks.  We are not planning any further v25.x releases, so if this
> problem doesn't happen with the latest pretest of Emacs 26.1, we
> will consider it resolved.

Well, function mark_memory hasn't been touched since 25.3, and the bug
won't have resolved itself in some magical way. ;-)

  for (pp = start; (void *) pp < end; pp += GC_POINTER_ALIGNMENT)
    {
      mark_maybe_pointer (*(void **) pp);
      mark_maybe_object (*(Lisp_Object *) pp);
    }

The loop is in steps of 4 but tries to access objects of size 8.

Backtrace with Emacs 26.0.91 (thanks to Rolf Eike Beer):
#0  0x002211a0 in mark_memory (start=0xffffacd8, end=0xffffc840) at alloc.c:4986
        pp = 0xffffacdc ""
#1  0x002211fc in mark_stack (bottom=0xffffc840 "", end=0xffffacd8 "") at alloc.c:5193
No locals.
#2  0x0031d1c8 in mark_one_thread (thread=0x66ab88 <main_thread>) at thread.c:616
        stack_top = 0xffffacd8
#3  0x0031d328 in mark_threads_callback (ignore=0x0) at thread.c:649
        thread_obj = -6917529027634353272
        iter = 0x66ab88 <main_thread>
#4  0x00221258 in flush_stack_call_func (func=0x31d2dc <mark_threads_callback>, arg=0x0) at alloc.c:5220
        end = 0xffffacd8
        self = 0x66ab88 <main_thread>
        sentry = {o = {__max_align_ll = -91431263796984, __max_align_ld = 0}}
#5  0x0031d368 in mark_threads () at thread.c:656
No locals.
#6  0x0022333c in garbage_collect_1 (end=0xffffaf00) at alloc.c:5997
        nextb = 0x0
        stack_top_variable = 0 '\000'
        i = 538
        message_p = false
        count = 25
        start = {tv_sec = 1521554084, tv_nsec = 118444958}
        retval = 0
        tot_before = 0
        total = {0, 0, 0, 4611686018427387904, 0, 4611686018427387904, -6917529027634762960, 4611686018434174144, 4611686018433697584, 0}
#7  0x00223f74 in Fgarbage_collect () at alloc.c:6168
        end = 0xffffaf00
        sentry = {o = {__max_align_ll = -89060441849851, __max_align_ld = 2}}
[...]

bug#30855: 25.3; temacs fails with bus error during garbage collection

[Eli Zaretskii]

> Date: Tue, 20 Mar 2018 15:00:28 +0100
> Cc: 30855@debbugs.gnu.org,
>     gentoo-bug@opensource.sf-tec.de
> From: Ulrich Mueller <ulm@gentoo.org>
> 
>   for (pp = start; (void *) pp < end; pp += GC_POINTER_ALIGNMENT)
>     {
>       mark_maybe_pointer (*(void **) pp);
>       mark_maybe_object (*(Lisp_Object *) pp);
>     }
> 
> The loop is in steps of 4 but tries to access objects of size 8.

So you are saying that we should be doing the below instead?

diff --git a/src/alloc.c b/src/alloc.c
index 9d0e2d3..18546ca 100644
--- a/src/alloc.c
+++ b/src/alloc.c
@@ -4983,7 +4983,8 @@ mark_memory (void *start, void *end)
   for (pp = start; (void *) pp < end; pp += GC_POINTER_ALIGNMENT)
     {
       mark_maybe_pointer (*(void **) pp);
-      mark_maybe_object (*(Lisp_Object *) pp);
+      if ((intptr_t) pp % GCALIGNMENT == 0)
+	mark_maybe_object (*(Lisp_Object *) pp);
     }
 }
 

bug#30855: 25.3; temacs fails with bus error during garbage collection

[Andreas Schwab]

On Mär 20 2018, Eli Zaretskii <eliz@gnu.org> wrote:

> So you are saying that we should be doing the below instead?
>
> diff --git a/src/alloc.c b/src/alloc.c
> index 9d0e2d3..18546ca 100644
> --- a/src/alloc.c
> +++ b/src/alloc.c
> @@ -4983,7 +4983,8 @@ mark_memory (void *start, void *end)
>    for (pp = start; (void *) pp < end; pp += GC_POINTER_ALIGNMENT)
>      {
>        mark_maybe_pointer (*(void **) pp);
> -      mark_maybe_object (*(Lisp_Object *) pp);
> +      if ((intptr_t) pp % GCALIGNMENT == 0)

That should be alignof(Lisp_Object).  A Lisp_Object only needs
Lisp_Object alignment.  GCALIGNMENT is about the _value_ of a
Lisp_Object (ie. the address of the Lisp object that this Lisp_Object
points to).

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

bug#30855: 25.3; temacs fails with bus error during garbage collection

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Cc: Ulrich Mueller <ulm@gentoo.org>,  Paul Eggert <eggert@cs.ucla.edu>,  30855@debbugs.gnu.org,  gentoo-bug@opensource.sf-tec.de
> Date: Tue, 20 Mar 2018 16:26:19 +0100
> 
> > --- a/src/alloc.c
> > +++ b/src/alloc.c
> > @@ -4983,7 +4983,8 @@ mark_memory (void *start, void *end)
> >    for (pp = start; (void *) pp < end; pp += GC_POINTER_ALIGNMENT)
> >      {
> >        mark_maybe_pointer (*(void **) pp);
> > -      mark_maybe_object (*(Lisp_Object *) pp);
> > +      if ((intptr_t) pp % GCALIGNMENT == 0)
> 
> That should be alignof(Lisp_Object).  A Lisp_Object only needs
> Lisp_Object alignment.  GCALIGNMENT is about the _value_ of a
> Lisp_Object (ie. the address of the Lisp object that this Lisp_Object
> points to).

Right, thanks.

Ulrich, please see if that fixes this problem.

bug#30855: 25.3; temacs fails with bus error during garbage collection

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 452 bytes --]

Even with the fix the code assumes that Lisp_Object is aligned at least 
as strictly as void *; this should be verified. Plus, if the alignments 
are the same Emacs can avoid a runtime check each time through the loop, 
which should help branch prediction. I installed the attached into 
master; if it fixes Ulrich's problem I think this should be backported 
to emacs-26. Thanks to Ulrich, Eli, and Andreas for reporting this and 
suggesting the fix.

[-- Attachment #2: 0001-Port-to-32-bit-sparc64.patch --]
[-- Type: text/x-patch, Size: 1058 bytes --]

From 59abd64e9a448bbc5e375a9238d55074d3c9ba11 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Tue, 20 Mar 2018 09:54:20 -0700
Subject: [PATCH] Port to 32-bit sparc64

Problem reported by Ulrich Mueller; fix suggested by Eli Zaretskii
and Andreas Schwab (Bug#30855).
* src/alloc.c (mark_memory): Call mark_maybe_object only on
pointers that are properly aligned for Lisp_Object.
---
 src/alloc.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/alloc.c b/src/alloc.c
index f97b99c0f3..da01173fba 100644
--- a/src/alloc.c
+++ b/src/alloc.c
@@ -4981,7 +4981,11 @@ mark_memory (void *start, void *end)
   for (pp = start; (void *) pp < end; pp += GC_POINTER_ALIGNMENT)
     {
       mark_maybe_pointer (*(void **) pp);
-      mark_maybe_object (*(Lisp_Object *) pp);
+
+      verify (alignof (Lisp_Object) % GC_POINTER_ALIGNMENT == 0);
+      if (alignof (Lisp_Object) == GC_POINTER_ALIGNMENT
+	  || (uintptr_t) pp % alignof (Lisp_Object) == 0)
+	mark_maybe_object (*(Lisp_Object *) pp);
     }
 }
 
-- 
2.14.3

bug#30855: 25.3; temacs fails with bus error during garbage collection

[Eli Zaretskii]

> Cc: ulm@gentoo.org, 30855@debbugs.gnu.org, gentoo-bug@opensource.sf-tec.de
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Tue, 20 Mar 2018 09:58:12 -0700
> 
> I installed the attached into master; if it fixes Ulrich's problem I
> think this should be backported to emacs-26.

I'm okay with backporting, unless the configuration where it happens
is extremely rare, so much so that we can get away with this as a
"known problem".

Thanks.

bug#30855: 25.3; temacs fails with bus error during garbage collection

[Ulrich Mueller]

>>>>> On Tue, 20 Mar 2018, Paul Eggert wrote:

> I installed the attached into master; if it fixes Ulrich's problem
> I think this should be backported to emacs-26.

Thanks. This fixes the build on sparc both for 25.3 and 26.0.91
(tested by Rolf Eike Beer, see https://bugs.gentoo.org/647238#c18).


>>>>> On Tue, 20 Mar 2018, Eli Zaretskii wrote:

> I'm okay with backporting, unless the configuration where it happens
> is extremely rare, so much so that we can get away with this as a
> "known problem".

I would really appreciate if this could be included with Emacs 26.
It would be less than ideal if we (Gentoo) needed a downstream patch
for the initial version because otherwise it won't even build on
sparc.

Also, doesn't this bug affect other architectures too, and at least
cause a performance penalty for unaligned access?

bug#30855: 25.3; temacs fails with bus error during garbage collection

[Paul Eggert]

On 03/20/2018 02:19 PM, Ulrich Mueller wrote:
> Also, doesn't this bug affect other architectures too, and at least
> cause a performance penalty for unaligned access?

It might cause crashes on other (presumably less-common) architectures, 
which is worrisome.

The performance penalty is not something we'd want to worry about in the 
emacs-26 branch, since we don't want to assume that the compiler is 
storing Lisp words on fast-aligned boundaries; this is why we're using 
alignof instead of __alignof__. So the patch does not address the issue 
of optimizing for compilers that use only fast-aligned Lisp words (and I 
doubt whether it's worth worrying about, even in the master branch).

Although 32-bit sparc64 is rare compared to x86-64, I wouldn't consider 
it to be "extremely rare" in an absolute sense (at least, not for the 
next several years; ask me again after 2038 :-). Perhaps I'm biased by 
the fact that one of our department's production servers is still 
regularly used that way, but whatever. I backported the patch to the 
emacs-26 branch and am closing Bug#30855.

bug#30855: 25.3; temacs fails with bus error during garbage collection

[Eli Zaretskii]

> Date: Tue, 20 Mar 2018 22:19:37 +0100
> Cc: Paul Eggert <eggert@cs.ucla.edu>,
>     schwab@suse.de,
>     30855@debbugs.gnu.org,
>     gentoo-bug@opensource.sf-tec.de
> From: Ulrich Mueller <ulm@gentoo.org>
> 
> Also, doesn't this bug affect other architectures too

Building a 32-bit Emacs --with-wide-int on a 64-bit system is quite
rare, and at least the x86_64 systems don't trigger SIGBUS in this
case.