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
On Tue, Oct 7, 2014 at 5:15 PM, Renato Golin <renato.golin at linaro.org> wrote:> 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?> I can't think of a way to avoid this without accepting any 2-digit > line number... > > Any ideas? > > cheers, > --renato
On 7 October 2014 20:55, Evgeniy Stepanov <eugenis at google.com> wrote:> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: asan-arm-err.zip Type: application/zip Size: 1865 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141008/c46a7221/attachment.zip>