From: Eli Zaretskii <eliz@gnu.org>
To: Jim Meyering <jim@meyering.net>
Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org
Subject: Re: building/using address-sanitizer-enabled emacs?
Date: Tue, 09 May 2017 18:18:08 +0300 [thread overview]
Message-ID: <83y3u6awjz.fsf@gnu.org> (raw)
In-Reply-To: <CA+8g5KEYkG7yyG_uwefcaa_SP71vNp_boyaQeqMqeDE-6zaYGg@mail.gmail.com> (message from Jim Meyering on Mon, 8 May 2017 22:48:06 -0700)
> From: Jim Meyering <jim@meyering.net>
> Date: Mon, 8 May 2017 22:48:06 -0700
> Cc: Paul Eggert <eggert@cs.ucla.edu>, emacs-devel <emacs-devel@gnu.org>
>
> 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
I admit that I don't understand this report. At the point where the
report claims there was buffer overflow, child_setup is not in the
call stack, because it is/was called in another process after vfork:
the callstack shows the stack of the Emacs process, whereas
child_setup is called by a child process. So either the report shows
a stack of a wrong process, or something else is going on. Or maybe I
simply don't understand how to read this report.
next prev parent reply other threads:[~2017-05-09 15:18 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
2017-05-09 15:18 ` Eli Zaretskii [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83y3u6awjz.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=eggert@cs.ucla.edu \
--cc=emacs-devel@gnu.org \
--cc=jim@meyering.net \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.