[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: building/using address-sanitizer-enabled emacs?
From: |
Jim Meyering |
Subject: |
Re: building/using address-sanitizer-enabled emacs? |
Date: |
Tue, 9 May 2017 10:06:29 -0700 |
On Tue, May 9, 2017 at 8:18 AM, Eli Zaretskii <address@hidden> wrote:
>> From: Jim Meyering <address@hidden>
>> Date: Mon, 8 May 2017 22:48:06 -0700
>> Cc: Paul Eggert <address@hidden>, emacs-devel <address@hidden>
>>
>> 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.
Thanks for looking.
I confess I have not done so. Does this caveat apply?
HINT: this may be a false positive if your program uses some custom
stack unwind mechanism or swapcontext
- building/using address-sanitizer-enabled emacs?, Jim Meyering, 2017/05/06
- Re: building/using address-sanitizer-enabled emacs?, Paul Eggert, 2017/05/07
- Re: building/using address-sanitizer-enabled emacs?, Jim Meyering, 2017/05/07
- Re: building/using address-sanitizer-enabled emacs?, Eli Zaretskii, 2017/05/07
- Re: building/using address-sanitizer-enabled emacs?, Paul Eggert, 2017/05/08
- Re: building/using address-sanitizer-enabled emacs?, Eli Zaretskii, 2017/05/08
- Re: building/using address-sanitizer-enabled emacs?, Paul Eggert, 2017/05/08
- Re: building/using address-sanitizer-enabled emacs?, Eli Zaretskii, 2017/05/08
- Re: building/using address-sanitizer-enabled emacs?, Jim Meyering, 2017/05/09
- Re: building/using address-sanitizer-enabled emacs?, Eli Zaretskii, 2017/05/09
- Re: building/using address-sanitizer-enabled emacs?,
Jim Meyering <=
- Re: building/using address-sanitizer-enabled emacs?, Eli Zaretskii, 2017/05/09
- Re: building/using address-sanitizer-enabled emacs?, Paul Eggert, 2017/05/09
- Re: building/using address-sanitizer-enabled emacs?, Jim Meyering, 2017/05/09
- Re: building/using address-sanitizer-enabled emacs?, Eli Zaretskii, 2017/05/09
- Re: building/using address-sanitizer-enabled emacs?, Paul Eggert, 2017/05/16
- Re: building/using address-sanitizer-enabled emacs?, Eli Zaretskii, 2017/05/16
- Re: building/using address-sanitizer-enabled emacs?, Paul Eggert, 2017/05/17
- Re: building/using address-sanitizer-enabled emacs?, Eli Zaretskii, 2017/05/17
- Re: building/using address-sanitizer-enabled emacs?, Paul Eggert, 2017/05/17
- Re: building/using address-sanitizer-enabled emacs?, Eli Zaretskii, 2017/05/18