unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Jim Meyering <jim@meyering.net>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Paul Eggert <eggert@cs.ucla.edu>, emacs-devel <emacs-devel@gnu.org>
Subject: Re: building/using address-sanitizer-enabled emacs?
Date: Mon, 8 May 2017 22:48:06 -0700	[thread overview]
Message-ID: <CA+8g5KEYkG7yyG_uwefcaa_SP71vNp_boyaQeqMqeDE-6zaYGg@mail.gmail.com> (raw)
In-Reply-To: <83fugfcp3b.fsf@gnu.org>

On Mon, May 8, 2017 at 9:04 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Cc: jim@meyering.net, emacs-devel@gnu.org
>> From: Paul Eggert <eggert@cs.ucla.edu>
>> Date: Mon, 8 May 2017 07:46:43 -0700
>>
>> Still, it would make Emacs performance worse and as I understand it this
>> is the main reason this approach has not been incorporated thus far.
>
> No, the reason is that the decision has not yet been made.
>
>> > This limitation is exactly the reason why we will soon have to decide
>> > whether we merge the branch and start using it, improving what can be
>> > improved and living with that which cannot, or keep using unexec
>> Those are not the only two choices available to us.
>
> What are the alternatives?

Hoping to make some progress, I built src/temacs with the kludgey
patch mentioned above (to work around the gcc7/8 ICE)

  san='-fsanitize-address-use-after-scope -fsanitize=address
-static-libasan'; ./configure --without-gpm --without-x
--with-x-toolkit=no --with-png=no --with-jpeg=no --with-sound=no
CFLAGS="-O0 -ggdb3 $san" LDFLAGS="$san" && make

[note, that the build failed due to the aforementioned global buffer
overrun while dumping, but it did succeed in building src/temacs]
and tried to use it on a foo.gpg file like this:

  echo foo |gpg -c > foo.gpg
  src/temacs -q foo.gpg 2> err

which reported this stack buffer overrun:

==24522==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7ffd5cc4d928 at pc 0x00000073fd76 bp 0x7ffd5cc4d910 sp
0x7ffd5cc4d908
READ of size 8 at 0x7ffd5cc4d928 thread T0
    #0 0x73fd75 in PSEUDOVECTORP /home/j/w/co/emacs/src/lisp.h:1454
    #1 0x7438c9 in BUFFERP /home/j/w/co/emacs/src/buffer.h:887
    #2 0x9c64b6 in call_process /home/j/w/co/emacs/src/callproc.c:702
    #3 0x9c41db in Fcall_process /home/j/w/co/emacs/src/callproc.c:270
    #4 0x8e3122 in funcall_subr /home/j/w/co/emacs/src/eval.c:2799
    #5 0x8e2aa1 in Ffuncall /home/j/w/co/emacs/src/eval.c:2744
    #6 0x8e072d in Fapply /home/j/w/co/emacs/src/eval.c:2375
    #7 0x8e3122 in funcall_subr /home/j/w/co/emacs/src/eval.c:2799
    #8 0x8e2aa1 in Ffuncall /home/j/w/co/emacs/src/eval.c:2744
    #9 0x98c89b in exec_byte_code /home/j/w/co/emacs/src/bytecode.c:641
    #10 0x8e4b55 in funcall_lambda /home/j/w/co/emacs/src/eval.c:3022
    #11 0x8e2ae1 in Ffuncall /home/j/w/co/emacs/src/eval.c:2746
    #12 0x98c89b in exec_byte_code /home/j/w/co/emacs/src/bytecode.c:641
    #13 0x8e4b55 in funcall_lambda /home/j/w/co/emacs/src/eval.c:3022
    #14 0x8e2ae1 in Ffuncall /home/j/w/co/emacs/src/eval.c:2746
    #15 0x98c89b in exec_byte_code /home/j/w/co/emacs/src/bytecode.c:641
    #16 0x8e4604 in funcall_lambda /home/j/w/co/emacs/src/eval.c:2944
    #17 0x8e2ae1 in Ffuncall /home/j/w/co/emacs/src/eval.c:2746
    #18 0x98c89b in exec_byte_code /home/j/w/co/emacs/src/bytecode.c:641
    #19 0x8e4604 in funcall_lambda /home/j/w/co/emacs/src/eval.c:2944
    #20 0x8e2ae1 in Ffuncall /home/j/w/co/emacs/src/eval.c:2746
    #21 0x98c89b in exec_byte_code /home/j/w/co/emacs/src/bytecode.c:641
    #22 0x8e4604 in funcall_lambda /home/j/w/co/emacs/src/eval.c:2944
    #23 0x8e2ae1 in Ffuncall /home/j/w/co/emacs/src/eval.c:2746
    #24 0x8e072d in Fapply /home/j/w/co/emacs/src/eval.c:2375
    #25 0x8e3122 in funcall_subr /home/j/w/co/emacs/src/eval.c:2799
    #26 0x8e2aa1 in Ffuncall /home/j/w/co/emacs/src/eval.c:2744
    #27 0x98c89b in exec_byte_code /home/j/w/co/emacs/src/bytecode.c:641
    #28 0x8e4604 in funcall_lambda /home/j/w/co/emacs/src/eval.c:2944
    #29 0x8e2ae1 in Ffuncall /home/j/w/co/emacs/src/eval.c:2746
    #30 0x8e1f8d in call6 /home/j/w/co/emacs/src/eval.c:2649
    #31 0x8034eb in Finsert_file_contents /home/j/w/co/emacs/src/fileio.c:3602
    #32 0x8e367f in funcall_subr /home/j/w/co/emacs/src/eval.c:2831
    #33 0x8e2aa1 in Ffuncall /home/j/w/co/emacs/src/eval.c:2744
    #34 0x98c89b in exec_byte_code /home/j/w/co/emacs/src/bytecode.c:641
    #35 0x8e4604 in funcall_lambda /home/j/w/co/emacs/src/eval.c:2944
    #36 0x8e2ae1 in Ffuncall /home/j/w/co/emacs/src/eval.c:2746
    #37 0x98c89b in exec_byte_code /home/j/w/co/emacs/src/bytecode.c:641
    #38 0x8e4604 in funcall_lambda /home/j/w/co/emacs/src/eval.c:2944
    #39 0x8e2ae1 in Ffuncall /home/j/w/co/emacs/src/eval.c:2746
    #40 0x98c89b in exec_byte_code /home/j/w/co/emacs/src/bytecode.c:641
    #41 0x8e4604 in funcall_lambda /home/j/w/co/emacs/src/eval.c:2944
    #42 0x8e2ae1 in Ffuncall /home/j/w/co/emacs/src/eval.c:2746
    #43 0x98c89b in exec_byte_code /home/j/w/co/emacs/src/bytecode.c:641
    #44 0x8e4604 in funcall_lambda /home/j/w/co/emacs/src/eval.c:2944
    #45 0x8e2ae1 in Ffuncall /home/j/w/co/emacs/src/eval.c:2746
    #46 0x98c89b in exec_byte_code /home/j/w/co/emacs/src/bytecode.c:641
    #47 0x8e4604 in funcall_lambda /home/j/w/co/emacs/src/eval.c:2944
    #48 0x8e2ae1 in Ffuncall /home/j/w/co/emacs/src/eval.c:2746
    #49 0x98c89b in exec_byte_code /home/j/w/co/emacs/src/bytecode.c:641
    #50 0x8e4604 in funcall_lambda /home/j/w/co/emacs/src/eval.c:2944
    #51 0x8e3f96 in apply_lambda /home/j/w/co/emacs/src/eval.c:2881
    #52 0x8df8ab in eval_sub /home/j/w/co/emacs/src/eval.c:2265
    #53 0x8dda2c in Feval /home/j/w/co/emacs/src/eval.c:2042
    #54 0x8df175 in eval_sub /home/j/w/co/emacs/src/eval.c:2223
    #55 0x945574 in readevalloop /home/j/w/co/emacs/src/lread.c:1947
    #56 0x9425f5 in Fload /home/j/w/co/emacs/src/lread.c:1352
    #57 0x8df41e in eval_sub /home/j/w/co/emacs/src/eval.c:2234
    #58 0x8dda2c in Feval /home/j/w/co/emacs/src/eval.c:2042
    #59 0x751a34 in top_level_2 /home/j/w/co/emacs/src/keyboard.c:1121
    #60 0x8d9c05 in internal_condition_case /home/j/w/co/emacs/src/eval.c:1326
    #61 0x751a97 in top_level_1 /home/j/w/co/emacs/src/keyboard.c:1129
    #62 0x8d83e9 in internal_catch /home/j/w/co/emacs/src/eval.c:1091
    #63 0x751899 in command_loop /home/j/w/co/emacs/src/keyboard.c:1090
    #64 0x75033f in recursive_edit_1 /home/j/w/co/emacs/src/keyboard.c:697
    #65 0x7506dd in Frecursive_edit /home/j/w/co/emacs/src/keyboard.c:768
    #66 0x74bbb9 in main /home/j/w/co/emacs/src/emacs.c:1687
    #67 0x7f40c7732400 in __libc_start_main (/lib64/libc.so.6+0x20400)
    #68 0x40d369 in _start (/home/j/w/co/emacs/src/temacs+0x40d369)

Address 0x7ffd5cc4d928 is located in stack of thread T0 at offset 136 in frame
    #0 0x9c8c15 in child_setup /home/j/w/co/emacs/src/callproc.c:1179

  This frame has 2 object(s):
    [32, 40) 'display'
    [96, 104) 'tmp' <== Memory access at offset 136 overflows this variable
HINT: this may be a false positive if your program uses some custom
stack unwind mechanism or swapcontext
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow
/home/j/w/co/emacs/src/lisp.h:1454 in PSEUDOVECTORP
Shadow bytes around the buggy address:
  0x10002b981ad0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10002b981ae0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10002b981af0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10002b981b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10002b981b10: 00 00 00 00 f1 f1 f1 f1 00 f2 f2 f2 f2 f2 f2 f2
=>0x10002b981b20: 00 f2 f2 f2 f3[f3]f3 f3 00 00 00 00 00 00 00 00
  0x10002b981b30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10002b981b40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10002b981b50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10002b981b60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10002b981b70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
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
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==24522==ABORTING



  reply	other threads:[~2017-05-09  5:48 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-07  3:40 building/using address-sanitizer-enabled emacs? Jim Meyering
2017-05-07 19:54 ` Paul Eggert
2017-05-07 21:44   ` Jim Meyering
2017-05-08  2:36   ` Eli Zaretskii
2017-05-08  5:42     ` Paul Eggert
2017-05-08 14:39       ` Eli Zaretskii
2017-05-08 14:46         ` Paul Eggert
2017-05-08 16:04           ` Eli Zaretskii
2017-05-09  5:48             ` Jim Meyering [this message]
2017-05-09 15:18               ` Eli Zaretskii
2017-05-09 17:06                 ` Jim Meyering
2017-05-09 17:45                   ` Eli Zaretskii
2017-05-09 19:22               ` Paul Eggert
2017-05-09 22:49                 ` Jim Meyering
2017-05-10  2:41                   ` Eli Zaretskii
2017-05-16 21:49                     ` Paul Eggert
2017-05-17  2:24                       ` Eli Zaretskii
2017-05-17 14:46                         ` Paul Eggert
2017-05-17 16:06                           ` Eli Zaretskii
2017-05-17 20:05                             ` Paul Eggert
2017-05-18  4:15                               ` Eli Zaretskii
2017-05-09 23:15 ` Philipp Stephani
2017-05-10  2:42   ` Eli Zaretskii
2017-05-10 22:24     ` Philipp Stephani
2017-05-13  8:02       ` Eli Zaretskii
2017-05-13 15:08         ` [PATCH] Fix use of sockaddr_in Philipp Stephani
2017-05-13 16:52           ` Eli Zaretskii
2017-05-13 19:14             ` Andreas Schwab
2017-05-13 19:29               ` Eli Zaretskii
2017-05-13 20:05                 ` Andreas Schwab
2017-05-14  2:32                   ` Eli Zaretskii
2017-05-14  6:11                     ` Andreas Schwab
2017-05-14 14:20                       ` Eli Zaretskii
2017-05-15  6:15                         ` Paul Eggert
2017-05-15  9:04                           ` Philipp Stephani
2017-05-17 20:38                             ` Paul Eggert
2017-05-27 11:35                               ` Philipp Stephani
2017-05-17 15:16                           ` Eli Zaretskii
2017-05-17 20:15                             ` Paul Eggert
2017-05-14 10:28           ` Lars Ingebrigtsen
2017-05-14 19:06             ` Philipp Stephani

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CA+8g5KEYkG7yyG_uwefcaa_SP71vNp_boyaQeqMqeDE-6zaYGg@mail.gmail.com \
    --to=jim@meyering.net \
    --cc=eggert@cs.ucla.edu \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).