GNU bug report logs - #16427
unexec doesn't work with GCC AddressSanitizer

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 16427 in the body.
You can then email your comments to 16427 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: Paul Eggert <eggert <at> cs.ucla.edu>
To: Emacs bug reports <bug-gnu-emacs <at> gnu.org>
Subject: unexec doesn't work with GCC AddressSanitizer
Date: Sun, 12 Jan 2014 15:26:01 -0800

It'd be better for debugging if Emacs worked with
the AddressSanitizer of recent GCC implementations,
but unfortunately there are problems.
On Fedora 20 x86-64, if I configure GNU Emacs using:

./configure CFLAGS='-g3 -O0 -fsanitize=address'

the resulting build fails during unexec, with
symptoms like those shone at the end of this message.
'unexec' is crashing here:

      memcpy (NEW_SECTION_H (nn).sh_offset + new_base, src,
              NEW_SECTION_H (nn).sh_size);

presumably because SRC contains holes that have been sanitized.

This problem has been noted on emacs-devel in the past:

http://lists.gnu.org/archive/html/emacs-devel/2012-06/msg00600.html
http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg01046.html

but it's never gotten a formal bug report so I thought
I'd file one.

Here are the symptoms:

if test "no" = "yes"; then \
  rm -f bootstrap-emacs; \
  ln temacs bootstrap-emacs; \
else \
  ./temacs --batch --load loadup bootstrap || exit 1; \
  test "X" = X ||  -zex emacs; \
  mv -f emacs bootstrap-emacs; \
fi
Loading loadup.el (source)...
...
Finding pointers to doc strings...
Finding pointers to doc strings...done
Dumping under the name emacs
=================================================================
==30803== ERROR: AddressSanitizer: unknown-crash on address 0x000000c4c240 at pc 0x7ffff4e5bc2f bp 0x7fffffffc8a0 sp 0x7fffffffc048
READ of size 3342120 at 0x000000c4c240 thread T0
    #0 0x7ffff4e5bc2e (/usr/lib64/libasan.so.0.0.0+0xec2e)
    #1 0x886d9b (/home/eggert/src/gnu/emacs/static-checking/src/temacs+0x886d9b)
    #2 0x6e9b7b (/home/eggert/src/gnu/emacs/static-checking/src/temacs+0x6e9b7b)
    #3 0x8092c8 (/home/eggert/src/gnu/emacs/static-checking/src/temacs+0x8092c8)
    #4 0x802486 (/home/eggert/src/gnu/emacs/static-checking/src/temacs+0x802486)
    #5 0x808c65 (/home/eggert/src/gnu/emacs/static-checking/src/temacs+0x808c65)
    #6 0x8021fb (/home/eggert/src/gnu/emacs/static-checking/src/temacs+0x8021fb)
    #7 0x808c65 (/home/eggert/src/gnu/emacs/static-checking/src/temacs+0x808c65)
    #8 0x854caf (/home/eggert/src/gnu/emacs/static-checking/src/temacs+0x854caf)
    #9 0x852b0a (/home/eggert/src/gnu/emacs/static-checking/src/temacs+0x852b0a)
    #10 0x80957f (/home/eggert/src/gnu/emacs/static-checking/src/temacs+0x80957f)
    #11 0x808345 (/home/eggert/src/gnu/emacs/static-checking/src/temacs+0x808345)
    #12 0x6eca50 (/home/eggert/src/gnu/emacs/static-checking/src/temacs+0x6eca50)
    #13 0x805e18 (/home/eggert/src/gnu/emacs/static-checking/src/temacs+0x805e18)
    #14 0x6ecaac (/home/eggert/src/gnu/emacs/static-checking/src/temacs+0x6ecaac)
    #15 0x804aa9 (/home/eggert/src/gnu/emacs/static-checking/src/temacs+0x804aa9)
    #16 0x6ec97d (/home/eggert/src/gnu/emacs/static-checking/src/temacs+0x6ec97d)
    #17 0x6eba41 (/home/eggert/src/gnu/emacs/static-checking/src/temacs+0x6eba41)
    #18 0x6ebc24 (/home/eggert/src/gnu/emacs/static-checking/src/temacs+0x6ebc24)
    #19 0x6e819c (/home/eggert/src/gnu/emacs/static-checking/src/temacs+0x6e819c)
    #20 0x7fffed8e3d64 (/usr/lib64/libc-2.18.so+0x21d64)
    #21 0x417518 (/home/eggert/src/gnu/emacs/static-checking/src/temacs+0x417518)
0x000000c4c240 is located 32 bytes to the left of global variable 'Sredraw_frame (dispnew.c)' (0xc4c260) of size 48
Shadow bytes around the buggy address:
  0x0000801817f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000080181800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000080181810: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000080181820: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000080181830: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x000080181840: 00 00 00 00 00 00 00 00[00]00 00 00 00 00 00 00
  0x000080181850: 00 00 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 f9 f9
  0x000080181860: f9 f9 f9 f9 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9
  0x000080181870: 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9 00 00 00 00
  0x000080181880: 00 00 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 f9 f9
  0x000080181890: f9 f9 f9 f9 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:     fa
  Heap righ redzone:     fb
  Freed Heap region:     fd
  Stack left redzone:    f1
  Stack mid redzone:     f2
  Stack right redzone:   f3
  Stack partial redzone: f4
  Stack after return:    f5
  Stack use after scope: f8
  Global redzone:        f9
  Global init order:     f6
  Poisoned by user:      f7
  ASan internal:         fe
==30803== ABORTING
Makefile:814: recipe for target 'bootstrap-emacs' failed
make[1]: *** [bootstrap-emacs] Error 1
make[1]: Leaving directory '/home/eggert/src/gnu/emacs/static-checking/src'
Makefile:377: recipe for target 'src' failed
make: *** [src] Error 2

Compilation exited abnormally with code 2 at Sun Jan 12 15:01:53

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

From: Glenn Morris <rgm <at> gnu.org>
To: 16427 <at> debbugs.gnu.org
Subject: Re: bug#16427: unexec doesn't work with GCC AddressSanitizer
Date: Mon, 13 Jan 2014 12:29:59 -0500

I classed this as "important" because it seems to me to be something
that's, err, important, to fix at some point; but I don't know if it's
important enough for 24.4.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 16427-done <at> debbugs.gnu.org
Subject: Re: unexec doesn't work with GCC AddressSanitizer
Date: Tue, 18 Jun 2019 16:48:01 -0700

Closing this old bug as the portable dumper does work with AddressSanitizer.

Previous Next

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