This is an archive of the discontinued LLVM Phabricator instance.

[asan] disable fast unwind on ARM
AbandonedPublic

Authored by garious on May 16 2014, 6:44 PM.

Details

Reviewers
kcc
samsonov
Summary

Fast unwind is disabled for aarch64. Following suit. This patch fixes the following lit tests:

Linux/malloc_delete_mismatch.cc
Posix/start-deactivated.cc
deep_stack_uaf.cc
double-free.cc
invalid-free.cc
large_func_test.cc

Diff Detail

Event Timeline

garious updated this revision to Diff 9501.May 16 2014, 6:44 PM
garious retitled this revision from to [asan] disable fast unwind on ARM.
garious updated this object.
garious edited the test plan for this revision. (Show Details)
garious added a reviewer: samsonov.
garious added a subscriber: Unknown Object (MLST).
kcc added a subscriber: kcc.May 18 2014, 11:37 PM

We do use fast unwind on Android ARM -- it is a performance-critical
feature, please don't disable it, but fix instead.
eugenis@ knows the details.

garious abandoned this revision.May 19 2014, 10:02 AM
garious updated this revision to Diff 9591.May 19 2014, 4:13 PM
garious added a reviewer: kcc.
garious removed a subscriber: kcc.

Per Kostya, this version does not disable fast unwind on Android.

With this patch, the error messages are significantly more useful. Without this patch, in the use-after-free test for example, the stack trace only has references to the 'malloc/free' wrappers in the ASan runtime and not references to anything in use-after-free.cc.

kcc edited edge metadata.May 19 2014, 9:14 PM

I think this is a mistake.
The slow unwinder is so terribly slow that you will not be able to use asan
on anything other than small test cases.
Instead, you need to make the fast unwinder work by enabling frame pointers
at compile time.
We do it on Android ARM, so I think this can and should be done on Linux
ARM as well.

Note also, that there are run-time flags that control the unwinder:
fast_unwind_on_fatal0Use fast unwinder when found a bug. The fast one
relies on frame pointers, while slow one does not. See also
CallStackhttps://code.google.com/p/address-sanitizer/wiki/CallStack
fast_unwind_on_malloc1Same as fast_unwind_on_fatal, but control unwinding
inside malloc/free, i.e. performance critical. See also
CallStackhttps://code.google.com/p/address-sanitizer/wiki/CallStack
--kcc

kcc added a subscriber: eugenis.May 19 2014, 9:15 PM

+eugenis

Fast stack unwind should work on ARM for Clang-compiled code, no matter Android or not.
It requires -marm -fno-omit-frame-pointer.

Fast stack unwind should work on ARM for Clang-compiled code, no matter Android or not.
It requires -marm -fno-omit-frame-pointer.

AFAIK supporting frame pointer violates standard ARM ABIs so this will force user to recompile complete stack (glibc and other system libs). That's perfectly fine for some users but I doubt about majority. Are we sure that fast_unwind_on_malloc should be default on platforms without default frame pointer?

It's quite uncommon to have frame pointers in glibc or system libraries anyway, even on x86 linux.
But with the dwarf unwinder tool performance becomes completely unacceptable.

It's quite uncommon to have frame pointers in glibc or system libraries anyway, even on x86 linux.

Ok, you win.

Fast stack unwind should work on ARM for Clang-compiled code, no matter Android or not.

It requires -marm -fno-omit-frame-pointer.

Hmm, I'm not seeing that. Zooming in on "TestCases/double-free.cc", I see that it is being compiled with -fno-omit-frame-pointer (and -marm is the default for armv7 targets). I double-checked and recompiled with those flags tacked onto the end of the clang invocation, but the result is the same:

==12127==ERROR: AddressSanitizer: attempting double-free on 0x41e007f0 in thread T0:
    #0 0x7269b in free compiler-rt/lib/asan/asan_malloc_linux.cc:65
    #1 0x896e3 in main compiler-rt/test/asan/TestCases/double-free.cc:15
  LLVMSymbolizer: error reading file: No such file or directory.
    #2 0x40a142cb (/lib/arm-linux-gnueabi/libc.so.6+0x182cb)
  
  0x41e007f0 is located 0 bytes inside of 10-byte region [0x41e007f0,0x41e007fa)
  freed by thread T0 here:
    #0 0x7269b in free compiler-rt/lib/asan/asan_malloc_linux.cc:65
  
  previously allocated by thread T0 here:
    #0 0x72859 in malloc compiler-rt/lib/asan/asan_malloc_linux.cc:75
  
  SUMMARY: AddressSanitizer: double-free compiler-rt/lib/asan/asan_malloc_linux.cc:65 free
  ==12127==ABORTING

What am I missing?

garious abandoned this revision.May 27 2014, 2:48 PM