GNU bug report logs - #22061
24.5; Build failure on sparc64, Bus Error in src/unexelf.c

Previous Next

Package: emacs;

Reported by: David Matthew Mattli <dmm <at> mattli.us>

Date: Mon, 30 Nov 2015 16:32:03 UTC

Severity: important

Found in version 24.5

Fixed in version 25.1

Done: Glenn Morris <rgm <at> gnu.org>

Bug is archived. No further changes may be made.

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

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#22061; Package emacs. (Mon, 30 Nov 2015 16:32:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to David Matthew Mattli <dmm <at> mattli.us>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Mon, 30 Nov 2015 16:32:03 GMT) Full text and rfc822 format available.

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

From: David Matthew Mattli <dmm <at> mattli.us>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.5; Build failure on sparc64, Bus Error in src/unexelf.c
Date: Mon, 30 Nov 2015 09:13:59 -0600
On sparc64 gnu/linux, when emacs is configured with
'--with-x-toolkit=lucid' the build fails with a Bus Error in the source
file 'src/unexelf.c'. This would occur because the sparc architecture
requires pointers to be naturally aligned, so 8-byte access to by 8-byte
aligned, 4-byte access to be 4-byte aligned, etc. Attempting to access
memory at an improperly aligned address results in a SIGBUS.

This was discovered while investigating a broken build
in Debian. The Debian build log showing the error is here:
https://buildd.debian.org/status/fetch.php?pkg=emacs24&arch=sparc64&ver=24.5%2B1-5&stamp=1448688813

I've also reproduced the problem with the latest master branch of the
git tree from this morning. By running the failing command in gdb I
found that the SIGBUS is occuring in the file 'src/unexelf.c'. The crash
occurs when it's walking through the section headers, around line 411:

  /* Walk through all section headers, copying data and updating.  */
  for (n = 1; n < old_file_h->e_shnum; n++)
    {
      caddr_t src;
      ElfW (Shdr) *old_shdr = &OLD_SECTION_H (n);
      ElfW (Shdr) *new_shdr = &NEW_SECTION_H (n);

      if (new_shdr->sh_type == SHT_NOBITS           // <======
	  && new_shdr->sh_addr >= old_bss_addr
	  && (new_shdr->sh_addr + new_shdr->sh_size
	      <= old_bss_addr + old_bss_size))
	{

For the Debian build failure I was able to determine where the
misalignment was introduced but it seems this file has changed a
lot. You can see the Debian bug details here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806667

Looking at frame #0 in the backtrace below I can see that
'old_bss_offset', 'new_data2_size', and 'new_data2_offset' are
unaligned, those may be the problem if they are added to a pointer that
is later used in a memory access that requires alignment.

Let me know if I can do anything to help fix this issue. I can give
emacs developers access to a sparc64 dev box, etc.

$ git log -n 1

commit c77b816bc3d8fc242b95c04859803ffff5bb8210
Author: Stefan Monnier <monnier <at> iro.umontreal.ca>
Date:   Mon Nov 30 08:02:55 2015 -0500

    * lisp/calculator.el (calculator-define-key): Silence warning

    ...about unknown calculator-mode-map.

Here's the backtrace from gdb for the git tree build:

#0  unexec (new_name=0x1818d60 "/home/dmm/src/emacs/src/emacs", 
    old_name=0x1818d88 "/home/dmm/src/emacs/src/temacs") at unexelf.c:411
        src = <optimized out>
        new_file = 7
        old_file = 6
        new_file_size = 36500211
        old_base = 0xffff800111c06000 "\177ELF\002\002\001"
        new_base = 0xffff800112ca8000 "\177ELF\002\002\001"
        old_file_h = 0xffff800111c06000
        new_file_h = 0xffff800112ca8000
        old_program_h = <optimized out>
        new_program_h = <optimized out>
        old_section_h = 0xffff800112ca5c20
        new_section_h = 0xffff800114f76933
        old_section_names = 0xffff800112ca5ab5 ""
        new_section_names = <optimized out>
        old_bss_seg = <optimized out>
        new_bss_seg = 0xffff800112ca80e8
        old_bss_addr = 7402221
        new_bss_addr = 26468352
        old_bss_size = <optimized out>
        new_data2_size = 19066131
        old_bss_offset = 5305069
        new_data2_offset = 5305069
        n = 1
        old_bss_index = 25
        stat_buf = {st_dev = 2066, __pad1 = 0, st_ino = 14040, st_mode = 33261, st_nlink = 1, 
          st_uid = 1000, st_gid = 1000, st_rdev = 0, __pad2 = 0, st_size = 17434080, 
          st_blksize = 4096, st_blocks = 34048, st_atim = {tv_sec = 1448893442, 
            tv_nsec = 941694653}, st_mtim = {tv_sec = 1448893442, tv_nsec = 481675054}, 
          st_ctim = {tv_sec = 1448893442, tv_nsec = 491675480}, __glibc_reserved4 = 0, 
          __glibc_reserved5 = 0}
        old_file_size = 17434080
#1  0x00000000001e66c4 in Fdump_emacs (filename=25845268, symfile=<optimized out>)
    at emacs.c:2139
        tem = 0
#2  0x000000000025bb4c in eval_sub (form=<optimized out>) at eval.c:2126
        numargs = <optimized out>
        args_left = 0
        i = <optimized out>
        maxargs = 2
        argvals = {25857348, 25857316, 24384, 129, 7932928, 7932928, 7932928, 0}
        fun = 4338869
        val = <optimized out>
        original_args = 14874147
        count = <optimized out>
#3  0x000000000025be10 in Fprogn (body=<optimized out>) at eval.c:427
        val = 0
#4  0x000000000025ba5c in eval_sub (form=<optimized out>) at eval.c:2085
        numargs = <optimized out>
        args_left = 14502707
        i = <optimized out>
        maxargs = <optimized out>
        argvals = {8791798045857, 2472532, 0, 0, 1434632, 17026259, 8747139, 8622419}
        fun = 7379453
        val = <optimized out>
        original_args = 14502707
        count = <optimized out>
#5  0x000000000025ba5c in eval_sub (form=form <at> entry=12156979) at eval.c:2085
        numargs = <optimized out>
        args_left = 13550515
        i = <optimized out>
        maxargs = <optimized out>
        argvals = {25259892, 44256, 0, 0, 0, 2, 38928, 24384}
        fun = 7379549
        val = <optimized out>
        original_args = 13550515
        count = <optimized out>
#6  0x000000000027f754 in readevalloop (readcharfun=readcharfun <at> entry=24384, 
    stream=stream <at> entry=0x825960, sourcename=sourcename <at> entry=8539236, 
    printflag=printflag <at> entry=false, unibyte=unibyte <at> entry=0, readfun=readfun <at> entry=0, start=0, 
    end=<optimized out>) at lread.c:1908
        c = <optimized out>
        val = <optimized out>
        b = 0x0
        continue_reading_p = true
        lex_bound = <optimized out>
        whole_buffer = false
        first_sexp = <optimized out>
        macroexpand = 0
#7  0x000000000027fc40 in Fload (file=8538980, noerror=<optimized out>, nomessage=0, 
    nosuffix=<optimized out>, must_suffix=<optimized out>) at lread.c:1316
        stream = 0x825960
        fd = <optimized out>
        fd_index = 4
        found = 8539172
        efound = <optimized out>
        hist_file_name = 8539236
        newer = false
        compiled = false
        handler = <optimized out>
        safe_p = true
        fmode = 0x2f4128 "r"
        version = 0
#8  0x000000000025baec in eval_sub (form=<optimized out>) at eval.c:2137
        numargs = <optimized out>
        args_left = 0
        i = <optimized out>
        maxargs = 5
        argvals = {8538980, 0, 0, 0, 0, 8540208, 8791798047201, -140733123707272}
        fun = 7386853
        val = <optimized out>
        original_args = 8476163
        count = <optimized out>
#9  0x000000000025ef3c in Feval (form=<optimized out>, lexical=0) at eval.c:1953
No locals.
#10 0x000000000025aca4 in internal_condition_case (bfun=bfun <at> entry=0x1eaf14 <top_level_2>, 
    handlers=handlers <at> entry=18912, hfun=hfun <at> entry=0x1ef784 <cmd_error>) at eval.c:1309
        val = <optimized out>
        c = <optimized out>
#11 0x00000000001ed3a4 in top_level_1 (ignore=ignore <at> entry=0) at keyboard.c:1103
        ignore = 0
#12 0x000000000025aba8 in internal_catch (tag=tag <at> entry=45648, 
    func=func <at> entry=0x1ed33c <top_level_1>, arg=arg <at> entry=0) at eval.c:1073
        val = <optimized out>
        c = <optimized out>
#13 0x00000000001eaea4 in command_loop () at keyboard.c:1064
No locals.
#14 0x00000000001ef34c in recursive_edit_1 () at keyboard.c:671
        val = <optimized out>
#15 0x00000000001ef6f4 in Frecursive_edit () at keyboard.c:742
        buffer = <optimized out>
#16 0x0000000000112d38 in main (argc=<optimized out>, argv=0x7fefffff348) at emacs.c:1652
        dummy = 1058888
        stack_bottom_variable = 1 '\001'
        do_initial_setlocale = <optimized out>
        dumping = <optimized out>
        skip_args = 3
        rlim = {rlim_cur = 8720000, rlim_max = 18446744073709551615}
        no_loadup = <optimized out>
        junk = 0x0
        dname_arg = 0x0
        ch_to_dir = 0x0
        original_pwd = <optimized out>







In GNU Emacs 24.5.1 (sparc64-unknown-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2015-11-29 on sparky, modified by Debian
System Description:	Debian GNU/Linux unstable (sid)

Configured using:
 `configure --build sparc64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.5/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.5/site-lisp:/usr/share/emacs/site-lisp
 --build sparc64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib
 --libexecdir=/usr/lib --localstatedir=/var/lib
 --infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.5/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.5/site-lisp:/usr/share/emacs/site-lisp
 --with-x=yes --with-x-toolkit=lucid --with-toolkit-scroll-bars
 --without-gconf --without-gsettings 'CFLAGS=-g -O2
 -fstack-protector-strong -Wformat -Werror=format-security -Wall'
 CPPFLAGS=-D_FORTIFY_SOURCE=2 LDFLAGS=-Wl,-z,relro'

Important settings:
  value of $LANG: en_SG.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)...
Loading debian-ispell...
Loading /var/cache/dictionaries-common/emacsen-ispell-default.el (source)...done
Loading debian-ispell...done
Loading /var/cache/dictionaries-common/emacsen-ispell-dicts.el (source)...done
Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)...done
Loading /etc/emacs/site-start.d/50gtk-doc-tools.el (source)...done
Loading term/xterm...done
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list... [2 times]

Load-path shadows:
/usr/share/emacs/24.5/site-lisp/debian-startup hides /usr/share/emacs/site-lisp/debian-startup

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
help-fns mail-prsvr mail-utils help-mode easymenu xterm time-date
tooltip electric uniquify ediff-hook vc-hooks lisp-float-type mwheel
x-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list
newcomment lisp-mode prog-mode register page menu-bar rfn-eshadow timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer nadvice loaddefs button faces cus-face macroexp
files text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
dbusbind gfilenotify dynamic-setting font-render-setting x-toolkit x
multi-tty emacs)

Memory information:
((conses 16 75135 5336)
 (symbols 48 17800 0)
 (miscs 40 73 113)
 (strings 32 9429 3746)
 (string-bytes 1 258369)
 (vectors 16 7222)
 (vector-slots 8 342728 32825)
 (floats 8 66 291)
 (intervals 56 208 22)
 (buffers 960 14)
 (heap 1024 8358 811))




Added indication that bug 22061 blocks19759 Request was from Glenn Morris <rgm <at> gnu.org> to control <at> debbugs.gnu.org. (Mon, 30 Nov 2015 16:37:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#22061; Package emacs. (Mon, 30 Nov 2015 17:47:02 GMT) Full text and rfc822 format available.

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

From: David Matthew Mattli <dmm <at> mattli.us>
To: 22061 <at> debbugs.gnu.org
Subject: Re: bug#22061: Acknowledgement (24.5;
 Build failure on sparc64, Bus Error in src/unexelf.c)
Date: Mon, 30 Nov 2015 11:46:44 -0600
Looking at it some more I think I have a better understanding of what's
going on in the git master sources.

The SIGBUS occurs when accessing the pointer calculated with the
NEW_SECTION_H macro:

    static void *
    entry_address (void *section_h, ptrdiff_t idx, ptrdiff_t entsize)
    {
       char *h = section_h;
       return h + idx * entsize;
    }

    #define NEW_SECTION_H(n) \
      (*(ElfW (Shdr) *) entry_address (new_section_h, n,
      new_file_h->e_shentsize))

This should generate aligned addresses, assuming 'new_section_h' is
aligned because it's adding multiples of 'new_file_h->e_shentsize' which
is 64. However new_section_h is /not/ aligned so the output of the macro
is also unaligned.

    (gdb) print new_section_h
    $27 = (Elf64_Shdr *) 0xffff800114f76933
    (gdb) print (unsigned long)new_section_h % 8
    $28 = 3


The variable 'new_section_h' is assigned on line 380:

      new_section_h = (ElfW (Shdr) *) ((byte *) new_base +
      new_file_h->e_shoff);

So its the sum of new_base and 'new_file_h->e_shoff'. new_base is highly
aligned so the problem must be 'new_file_h->e_shoff'

    (gdb) print new_base
    $29 = (caddr_t) 0xffff800112ca8000 "\177ELF\002\002\001"
    (gdb) print new_file_h->e_shoff
    $30 = 36497715

In turn, 'new_file_h->e_shoff' s misalignment comes from when
new_data2_size is added to it on line 377.

    if (new_file_h->e_shoff >= old_bss_offset)
        new_file_h->e_shoff += new_data2_size;

Finally the value of new_data2_size is calculated on line 334:

  new_data2_size = new_bss_addr - old_bss_addr;

  (gdb) print (unsigned long)(new_data2_size) % 8
  $39 = 3

Because 'new_data2_size' is eventually added to 'new_section_h' it needs
to be aligned or 'new_section_h' has to be padded to a multiple of 8.

I think the easiest thing to do would be to round 'new_data2_size' to
the nearest multiple of 8.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#22061; Package emacs. (Mon, 30 Nov 2015 18:49:02 GMT) Full text and rfc822 format available.

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

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: David Matthew Mattli <dmm <at> mattli.us>
Cc: 22061 <at> debbugs.gnu.org
Subject: Re: bug#22061: Acknowledgement (24.5;
 Build failure on sparc64, Bus Error in src/unexelf.c)
Date: Mon, 30 Nov 2015 19:47:54 +0100
That should be fixed in 25.1, in commit c9fd597.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#22061; Package emacs. (Mon, 30 Nov 2015 19:48:01 GMT) Full text and rfc822 format available.

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

From: David Matthew Mattli <dmm <at> mattli.us>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 22061 <at> debbugs.gnu.org
Subject: Re: bug#22061: Acknowledgement (24.5;
 Build failure on sparc64, Bus Error in src/unexelf.c)
Date: Mon, 30 Nov 2015 13:47:14 -0600
Andreas Schwab <schwab <at> linux-m68k.org> writes:

> That should be fixed in 25.1, in commit c9fd597.
>
> Andreas.

Thanks for your reply. That commit does fix the problem. I wish I had
looked in the emacs-25 branch first because it builds without any
problems. I just assumed master was the latest sources.




bug marked as fixed in version 25.1, send any further explanations to 22061 <at> debbugs.gnu.org and David Matthew Mattli <dmm <at> mattli.us> Request was from Glenn Morris <rgm <at> gnu.org> to control <at> debbugs.gnu.org. (Mon, 30 Nov 2015 21:08:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Tue, 29 Dec 2015 12:24:03 GMT) Full text and rfc822 format available.

This bug report was last modified 9 years and 178 days ago.

Previous Next


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