GNU bug report logs - #30855
25.3; temacs fails with bus error during garbage collection

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 30855 in the body.
You can then email your comments to 30855 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ulrich Mueller <ulm <at> gentoo.org>
To: bug-gnu-emacs <at> gnu.org
Cc: Rolf Eike Beer <gentoo-bug <at> opensource.sf-tec.de>
Subject: 25.3; temacs fails with bus error during garbage collection
Date: Mon, 19 Mar 2018 16:23:34 +0100

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

Message #8 received at 30855 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ulrich Mueller <ulm <at> gentoo.org>
Cc: gentoo-bug <at> opensource.sf-tec.de, 30855 <at> debbugs.gnu.org
Subject: Re: bug#30855: 25.3;
 temacs fails with bus error during garbage collection
Date: Mon, 19 Mar 2018 21:19:01 +0200

> Date: Mon, 19 Mar 2018 16:23:34 +0100
> From: Ulrich Mueller <ulm <at> gentoo.org>
> Cc: Rolf Eike Beer <gentoo-bug <at> 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.

Message #11 received at 30855 <at> debbugs.gnu.org (full text, mbox):

From: Ulrich Mueller <ulm <at> gentoo.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gentoo-bug <at> opensource.sf-tec.de, 30855 <at> debbugs.gnu.org
Subject: Re: bug#30855: 25.3;
 temacs fails with bus error during garbage collection
Date: Tue, 20 Mar 2018 15:00:28 +0100

>>>>> 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}}
[...]

Message #14 received at 30855 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ulrich Mueller <ulm <at> gentoo.org>, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: gentoo-bug <at> opensource.sf-tec.de, 30855 <at> debbugs.gnu.org
Subject: Re: bug#30855: 25.3;
 temacs fails with bus error during garbage collection
Date: Tue, 20 Mar 2018 16:47:29 +0200

> Date: Tue, 20 Mar 2018 15:00:28 +0100
> Cc: 30855 <at> debbugs.gnu.org,
>     gentoo-bug <at> opensource.sf-tec.de
> From: Ulrich Mueller <ulm <at> 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);
     }
 }
 

Message #17 received at 30855 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> suse.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Ulrich Mueller <ulm <at> gentoo.org>, Paul Eggert <eggert <at> cs.ucla.edu>,
 gentoo-bug <at> opensource.sf-tec.de, 30855 <at> debbugs.gnu.org
Subject: Re: bug#30855: 25.3;
 temacs fails with bus error during garbage collection
Date: Tue, 20 Mar 2018 16:26:19 +0100

On Mär 20 2018, Eli Zaretskii <eliz <at> 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 <at> suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Message #20 received at 30855 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andreas Schwab <schwab <at> suse.de>
Cc: ulm <at> gentoo.org, eggert <at> cs.ucla.edu, gentoo-bug <at> opensource.sf-tec.de,
 30855 <at> debbugs.gnu.org
Subject: Re: bug#30855: 25.3;
 temacs fails with bus error during garbage collection
Date: Tue, 20 Mar 2018 18:40:51 +0200

> From: Andreas Schwab <schwab <at> suse.de>
> Cc: Ulrich Mueller <ulm <at> gentoo.org>,  Paul Eggert <eggert <at> cs.ucla.edu>,  30855 <at> debbugs.gnu.org,  gentoo-bug <at> 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.

Message #23 received at 30855 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>, Andreas Schwab <schwab <at> suse.de>
Cc: ulm <at> gentoo.org, gentoo-bug <at> opensource.sf-tec.de, 30855 <at> debbugs.gnu.org
Subject: Re: bug#30855: 25.3; temacs fails with bus error during garbage
 collection
Date: Tue, 20 Mar 2018 09:58:12 -0700

[Message part 1 (text/plain, inline)]

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.

[0001-Port-to-32-bit-sparc64.patch (text/x-patch, attachment)]

Message #26 received at 30855 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: schwab <at> suse.de, ulm <at> gentoo.org, gentoo-bug <at> opensource.sf-tec.de,
 30855 <at> debbugs.gnu.org
Subject: Re: bug#30855: 25.3; temacs fails with bus error during garbage
 collection
Date: Tue, 20 Mar 2018 19:15:48 +0200

> Cc: ulm <at> gentoo.org, 30855 <at> debbugs.gnu.org, gentoo-bug <at> opensource.sf-tec.de
> From: Paul Eggert <eggert <at> 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.

Message #29 received at 30855 <at> debbugs.gnu.org (full text, mbox):

From: Ulrich Mueller <ulm <at> gentoo.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: schwab <at> suse.de, Paul Eggert <eggert <at> cs.ucla.edu>,
 gentoo-bug <at> opensource.sf-tec.de, 30855 <at> debbugs.gnu.org
Subject: Re: bug#30855: 25.3; temacs fails with bus error during garbage
 collection
Date: Tue, 20 Mar 2018 22:19:37 +0100

>>>>> 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?

Message #34 received at 30855-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Ulrich Mueller <ulm <at> gentoo.org>, Eli Zaretskii <eliz <at> gnu.org>
Cc: schwab <at> suse.de, gentoo-bug <at> opensource.sf-tec.de, 30855-done <at> debbugs.gnu.org
Subject: Re: bug#30855: 25.3; temacs fails with bus error during garbage
 collection
Date: Tue, 20 Mar 2018 14:42:15 -0700

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.

Message #39 received at 30855 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ulrich Mueller <ulm <at> gentoo.org>
Cc: schwab <at> suse.de, eggert <at> cs.ucla.edu, gentoo-bug <at> opensource.sf-tec.de,
 30855 <at> debbugs.gnu.org
Subject: Re: bug#30855: 25.3; temacs fails with bus error during garbage
 collection
Date: Wed, 21 Mar 2018 08:20:57 +0200

> Date: Tue, 20 Mar 2018 22:19:37 +0100
> Cc: Paul Eggert <eggert <at> cs.ucla.edu>,
>     schwab <at> suse.de,
>     30855 <at> debbugs.gnu.org,
>     gentoo-bug <at> opensource.sf-tec.de
> From: Ulrich Mueller <ulm <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.