[LLVMdev] More ARM asan failures (original) (raw)

[LLVMdev] More ARM asan failures - Line number

Evgeniy Stepanov eugenis at google.com
Wed Oct 8 03🔞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_ _/home/linaro/devel/llvm/src/llvm/projects/compiler-rt/lib/asan/asanmalloclinux.cc:30_ _< #1 0xffffffff () Which is on x86:

_#0 0x490979 in interceptorfree /home/rengolin/devel/llvm/src/llvm/projects/compiler-rt/lib/asan/asanmalloclinux.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 libcstartmain (/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

More information about the llvm-dev mailing list