ASAN stack

44 views
Skip to first unread message

Bram Moolenaar

unread,
Nov 16, 2017, 5:11:43 PM11/16/17
to Dominique Pellé, vim...@googlegroups.com

Travis reported an error found by ASAN in test_terminal.
https://travis-ci.org/vim/vim/builds/302986836
It looks like this:

==18767== ERROR: AddressSanitizer: heap-use-after-free on address 0x606e00061740 at pc 0x75a165 bp 0x7ffdb4b30490 sp 0x7ffdb4b30488
READ of size 8 at 0x606e00061740 thread T0
#0 0x75a164 (/home/travis/build/vim/vim/src/vim+0x75a164)
#1 0x4bda78 (/home/travis/build/vim/vim/src/vim+0x4bda78)
#2 0x779be3 (/home/travis/build/vim/vim/src/vim+0x779be3)
#3 0x77a235 (/home/travis/build/vim/vim/src/vim+0x77a235)

I have been unable to reproduce this (with valgrind).
I did once have the test crash. But unable to repeat it.

It would be very helpful if these stack traces would show file
locations. Can we make that happen?

--
I think that you'll agree that engineers are very effective in their social
interactions. It's the "normal" people who are nuts.
(Scott Adams - The Dilbert principle)

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

Tony Mechelynck

unread,
Nov 16, 2017, 5:45:31 PM11/16/17
to vim_dev, Dominique Pellé
On Thu, Nov 16, 2017 at 11:11 PM, Bram Moolenaar <Br...@moolenaar.net> wrote:
[...]
> It would be very helpful if these stack traces would show file
> locations. Can we make that happen?

Did you run the test with the "unstripped" vim executable made under
./src by the linker, or with the "stripped" one produced (usually
under /usr/local or platform-dependent equivalent) by "make install"?

Best regards,
Tony.

Dominique Pellé

unread,
Nov 17, 2017, 1:53:14 AM11/17/17
to vim_dev
Bram Moolenaar wrote:

> Travis reported an error found by ASAN in test_terminal.
> https://travis-ci.org/vim/vim/builds/302986836
> It looks like this:
>
> ==18767== ERROR: AddressSanitizer: heap-use-after-free on address 0x606e00061740 at pc 0x75a165 bp 0x7ffdb4b30490 sp 0x7ffdb4b30488
> READ of size 8 at 0x606e00061740 thread T0
> #0 0x75a164 (/home/travis/build/vim/vim/src/vim+0x75a164)
> #1 0x4bda78 (/home/travis/build/vim/vim/src/vim+0x4bda78)
> #2 0x779be3 (/home/travis/build/vim/vim/src/vim+0x779be3)
> #3 0x77a235 (/home/travis/build/vim/vim/src/vim+0x77a235)
>
> I have been unable to reproduce this (with valgrind).
> I did once have the test crash. But unable to repeat it.
>
> It would be very helpful if these stack traces would show file
> locations. Can we make that happen?

When using clang -fsanitize=address, you either need to
to set up ASAN_SYMBOLIZER_PATH env variable as
described here:

https://github.com/google/sanitizers/wiki/AddressSanitizerCallStack

... or you can filter the asan report with the asan_symbolize.py
script to see function names:

$ asan_symbolize.py < asan.log

See:
https://github.com/llvm-mirror/compiler-rt/blob/master/lib/asan/scripts/asan_symbolize.py

When gcc -fsanitize=address (instead of clang -fsanitize=address), gcc
conveniently
shows function names automatically. See comments in:

https://tsdgeos.blogspot.nl/2014/03/asan-and-gcc-how-to-get-line-numbers-in.html

Asan implementation in gcc and clang have other differences. See:

https://https://github.com/google/sanitizers/wiki/AddressSanitizerClangVsGCC-(3.8-vs-6.0)github.com/google/sanitizers/wiki/AddressSanitizerClangVsGCC-(3.8-vs-6.0)

This links says:

=== BEGIN QUOTE ==
GCC uses embedded libbacktrace library for symbolization that's statically
linked with libasan. LLVM needs a separate llvm-symbolizer binary to
print nice reports.C uses embedded libbacktrace library for symbolization
that's statically linked with libasan. LLVM needs a separate
llvm-symbolizer binary to print nice reports.
=== END QUOTE ==

Regards
Dominique

Bram Moolenaar

unread,
Nov 17, 2017, 8:55:23 AM11/17/17
to vim...@googlegroups.com, Dominique Pellé
Thanks. Now if someone can turn that in the Travis instructions...

--
It's totally unfair to suggest - as many have - that engineers are socially
inept. Engineers simply have different objectives when it comes to social
interaction.

James McCoy

unread,
Nov 17, 2017, 9:50:11 AM11/17/17
to vim_dev
On Nov 17, 2017 01:53, "Dominique Pellé" <dominiq...@gmail.com> wrote:
Bram Moolenaar wrote:

> Travis reported an error found by ASAN in test_terminal.
> https://travis-ci.org/vim/vim/builds/302986836
> It looks like this:
>
> ==18767== ERROR: AddressSanitizer: heap-use-after-free on address 0x606e00061740 at pc 0x75a165 bp 0x7ffdb4b30490 sp 0x7ffdb4b30488
> READ of size 8 at 0x606e00061740 thread T0
>     #0 0x75a164 (/home/travis/build/vim/vim/src/vim+0x75a164)
>     #1 0x4bda78 (/home/travis/build/vim/vim/src/vim+0x4bda78)
>     #2 0x779be3 (/home/travis/build/vim/vim/src/vim+0x779be3)
>     #3 0x77a235 (/home/travis/build/vim/vim/src/vim+0x77a235)
>
> I have been unable to reproduce this (with valgrind).
> I did once have the test crash.  But unable to repeat it.
>
> It would be very helpful if these stack traces would show file
> locations.  Can we make that happen?

When using clang -fsanitize=address, you either need to
to set up ASAN_SYMBOLIZER_PATH env variable as
described here:

It's also supposed to work when llvm-symbolize is in $PATH, which it should be.  PATH is updated just before running the tests.

James

Dominique Pellé

unread,
Nov 17, 2017, 3:33:57 PM11/17/17
to vim_dev
i just checked that clang sanitizer should indeed show
symbols when llvm-symbolize is in the PATH. And I see that it
should be the case according to .travis.yml. Log also shows that
vim was compiled with -g. No idea why the stack did not contain
symbols then.

I can't reproduce the asan error with vim when running tests with
asan on my machine.

Dominique
Reply all
Reply to author
Forward
0 new messages