[LLVMdev] More ARM asan failures - Line number
eugenis at google.com
Wed Oct 8 03:18:53 PDT 2014
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
> < #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.
More information about the llvm-dev