More ARM asan failures - Line number

Hi Evgeniy,

Now that I can run check-asan without the AArch64 tests, there are a
number of ARM tests that fail with the wrong line number on the CHECK
line...

use-after-delete.cc:20:18: error: expected string not found in input
// CHECK-Linux: {{ #1 0x.* in main .*use-after-delete.cc:}}[[@LINE-10]]

<stdin>:9:33: note: with expression "@LINE-10" equal to "10"
#0 0x91ac7 in operator delete(void*) .../lib/asan/asan_new_delete.cc:98

<stdin>:16:75: note: possible intended match here
SUMMARY: AddressSanitizer: heap-use-after-free
.../test/asan/TestCases/use-after-delete.cc:11 main

Note that the line is 10+1. This is happening with a lot of the ARM
tests. It looks like the test case having one more line due to
lit/check not cleaning some of the meta lines (#REQUIRE etc).

I can't think of a way to avoid this without accepting any 2-digit
line number...

Any ideas?

cheers,
--renato

Hi Evgeniy,

Now that I can run check-asan without the AArch64 tests, there are a
number of ARM tests that fail with the wrong line number on the CHECK
line...

use-after-delete.cc:20:18: error: expected string not found in input
// CHECK-Linux: {{ #1 0x.* in main .*use-after-delete.cc:}}[[@LINE-10]]

<stdin>:9:33: note: with expression "@LINE-10" equal to "10"
#0 0x91ac7 in operator delete(void*) .../lib/asan/asan_new_delete.cc:98

<stdin>:16:75: note: possible intended match here
SUMMARY: AddressSanitizer: heap-use-after-free
.../test/asan/TestCases/use-after-delete.cc:11 main

Note that the line is 10+1. This is happening with a lot of the ARM
tests. It looks like the test case having one more line due to
lit/check not cleaning some of the meta lines (#REQUIRE etc).

Can you elaborate on this? Does it ever clean those lines? These
numbers are correct on multiple other platforms. I wonder if it's some
codegen peculiarity that leads to this off-by-one mistake? Can you go
down to the individual compile/run invocation and verify that line
numbers match (or do not match) the exact source being compiled?

Can you elaborate on this? Does it ever clean those lines? These
numbers are correct on multiple other platforms. I wonder if it's some
codegen peculiarity that leads to this off-by-one mistake? Can you go
down to the individual compile/run invocation and verify that line
numbers match (or do not match) the exact source being compiled?

It seems that the stack trace is not correct on ARM:

< #0 0x7966b in free
/home/linaro/devel/llvm/src/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:30
< #1 0xffffffff (<unknown module>)

Which is on x86:

    #0 0x490979 in __interceptor_free /home/rengolin/devel/llvm/src/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:30
    #1 0x4b365d in main /home/rengolin/devel/llvm/src/compiler-rt/test/asan/TestCases/use-after-free.cc:10:3
    #2 0x7f560894703f in __libc_start_main (/usr/lib/libc.so.6+0x2003f)

And that's why the line number is different.

Could it be the stack walker issue on ARM we discussed during the GNU cauldron?

cheers,
--renato

asan-arm-err.zip (1.82 KB)

Can you elaborate on this? Does it ever clean those lines? These
numbers are correct on multiple other platforms. I wonder if it's some
codegen peculiarity that leads to this off-by-one mistake? Can you go
down to the individual compile/run invocation and verify that line
numbers match (or do not match) the exact source being compiled?

It seems that the stack trace is not correct on ARM:

< #0 0x7966b in free
/home/linaro/devel/llvm/src/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:30
< #1 0xffffffff (<unknown module>)

Which is on x86:

    #0 0x490979 in __interceptor_free /home/rengolin/devel/llvm/src/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:30
    #1 0x4b365d in main /home/rengolin/devel/llvm/src/compiler-rt/test/asan/TestCases/use-after-free.cc:10:3
    #2 0x7f560894703f in __libc_start_main (/usr/lib/libc.so.6+0x2003f)

And that's why the line number is different.

Could it be the stack walker issue on ARM we discussed during the GNU cauldron?

The frame pointer issue? I think it was fixed recently (r217079), and
even if not, in this code both modules are compiled with clang.
Maybe a bug in r217079?
Something you could try: ASAN_OPTIONS=fast_unwind_on_malloc=0 should
switch to cfi unwinder and fix the stack trace, but that's not a
solution to the problem.

Is this when compiling Clang? The file? or running the final binary?

--renato

When running the final binary.

Same thing... :frowning:

Should I bisect where that got broken? Do you have any way of testing
that locally? This is just a basic CMake build on ARM, nothing
special. "ninja check-asan".

cheers,
--renato

When running the final binary.

Same thing... :frowning:

Should I bisect where that got broken? Do you have any way of testing
that locally? This is just a basic CMake build on ARM, nothing
special. "ninja check-asan".

Did it ever work? The test says XFAIL: arm-linux-gnueabi.
We know that it works on Android-arm, which is essentially the same,
maybe with a few different default settings in the driver.

Did it ever work?

I really don't know. I'm just trying to make it work now and haven't
tried it before for real.

The test says XFAIL: arm-linux-gnueabi.
We know that it works on Android-arm, which is essentially the same,
maybe with a few different default settings in the driver.

This platform is hard-float, that's why the XFAIL doesn't work. But
I'm surprised that it passes on Android (which is arm-gnueabi) and not
on "arm-linux-gnueabi".

Anyway, do you think we should mark all the failing tests XFAIL on
gnueabihf for now?

http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-full/builds/713

We can at least have a green buildbot and work on them later. I'm not
particularly worried about ASAN for now, just making sure I can
compile compiler-rt and use it for the next step, running the
test-suite with it. But I can't do that while this bot is red.

cheers,
--renato

Android is arm-linux-androideabi. Historically there were a few cases
in llvm/clang where a switch handled a number of *eabi variants but
missed androideabi.

Did it ever work?

I really don't know. I'm just trying to make it work now and haven't
tried it before for real.

The test says XFAIL: arm-linux-gnueabi.
We know that it works on Android-arm, which is essentially the same,
maybe with a few different default settings in the driver.

This platform is hard-float, that's why the XFAIL doesn't work. But
I'm surprised that it passes on Android (which is arm-gnueabi) and not
on "arm-linux-gnueabi".

Anyway, do you think we should mark all the failing tests XFAIL on
gnueabihf for now?

I don't mind.

Btw, I did it wrong the last time. Now doing it right, yes, the ASAN
option does fix the problem.

Does that mean that the quick unwinder is broken on ARM?

I'll still mark them as XFAIL, at least until we have a proper fix.

cheers,
--renato

Either that, or we are missing frame pointers for some reason.
I think we add frame pointer flags (normal and leaf) in one of the lit.*.cfg