[LLVMdev] More ARM asan failures - Line number

[Evgeniy Stepanov]

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