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>
On Wed, Oct 8, 2014 at 2:10 PM, Renato Golin <renato.golin at linaro.org> wrote:> 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?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.> > cheers, > --renato
On 8 October 2014 11:18, Evgeniy Stepanov <eugenis at google.com> wrote:> 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
On 8 October 2014 11:18, Evgeniy Stepanov <eugenis at google.com> wrote:> 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.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