GNU bug report logs -
#22061
24.5; Build failure on sparc64, Bus Error in src/unexelf.c
Previous Next
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.
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):
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):
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):
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):
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.