[PATCH] D73557: [GWP-ASan] Crash Handler API.

Mitch Phillips via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jan 29 16:41:19 PST 2020


hctim marked 10 inline comments as done.
hctim added inline comments.


================
Comment at: compiler-rt/lib/gwp_asan/guarded_pool_allocator.cpp:113
     size_t BacktraceLength =
         Backtrace(UncompressedBuffer, kMaxTraceLengthToCollect);
     DeallocationTrace.TraceSize = compression::pack(
----------------
eugenis wrote:
> If you move backtrace collection (but maybe not compression) to the caller, you can get rid of the ugly passing-by-reference of RecursiveGuard.
> 
Refactored a little here.


================
Comment at: compiler-rt/lib/gwp_asan/guarded_pool_allocator.cpp:130
   if (Opts.SampleRate < 0) {
-    Opts.Printf("GWP-ASan Error: SampleRate is < 0.\n");
-    exit(EXIT_FAILURE);
+    assert(false && "GWP-ASan Error: SampleRate is < 0.");
+    __builtin_trap();
----------------
eugenis wrote:
> hctim wrote:
> > No `Printf` maintained internally any more, so we assert and trap instead.
> why do you need trap after assert?
> 
> Factor out CHECK() implemented (on Android) as set_abort_message() + abort?
> 
In case of `-DNDEBUG`.

Done.


================
Comment at: compiler-rt/lib/gwp_asan/guarded_pool_allocator.h:168
+  // servicing any further allocations permanently.
+  void stop();
+
----------------
eugenis wrote:
> Tries to stop. Not very hard.
> If we really wanted to, we could make the mutex recursive.
We need something to set `RecursiveGuard = true` in the in-process crash handler. The `tryLock` is mostly there as a best-effort as we might take some time uncompressing traces/getting the access backtrace, and it reduces the chance of our metadata getting corrupted.

Not sure what we could do to stop harder here :(


================
Comment at: compiler-rt/lib/gwp_asan/options.inc:33
 
+// Developer note - This option is not actually processed by GWP-ASan itself. It
+// is included here so that a user can specify whether they want signal handlers
----------------
eugenis wrote:
> Would it be better to move this option to scudo then if it is unused?
My assumption is that some new consumer may chose to use the sanitizer_common flag parser (which we include optionally under `optional/options_parser.h`). In that case, it's nice to have this flag be user-controlled. I'm not super attached to it being here though, LMK.


================
Comment at: compiler-rt/lib/gwp_asan/tests/CMakeLists.txt:8
+  -g
+  -fno-optimize-sibling-calls # Used in crash_handler_api.cpp (GetAllocation())
+)
----------------
eugenis wrote:
> Don't understand the comment. Does this optimization break the code? Why? Where did  -O2 go?
It ensured that `call -> jmp` optimisation didn't take place, but `optnone` is a much better sol'n.


================
Comment at: compiler-rt/lib/gwp_asan/tests/crash_handler_api.cpp:1
+//===-- crash_handler_api.cpp -----------------------------------*- C++ -*-===//
+//
----------------
eugenis wrote:
> hctim wrote:
> > New tests for the crash handler API.
> This test makes my head hurt :(
> I don't see why it needs to actually send and receive signals to test this API.
> Also, the fuzzy match logic seems to be testing an implementation of backtrace. This also seems irrelevant. I'd simply supply a mock backtrace callback.
Let me refactor this to not go through the actual allocator + crashing stuff. I refactored this test from some working branch that had wildly different assumptions.


================
Comment at: compiler-rt/lib/gwp_asan/tests/crash_handler_api.cpp:216
+
+  uintptr_t IntPtr = reinterpret_cast<uintptr_t>(Ptr);
+
----------------
eugenis wrote:
> why not IntPtr = &Intptr ?
> 
Sorry, I don't follow...


================
Comment at: compiler-rt/lib/scudo/standalone/CMakeLists.txt:25
+append_list_if(COMPILER_RT_HAS_OMIT_FRAME_POINTER_FLAG
+               -mno-omit-leaf-frame-pointer SCUDO_CFLAGS)
+
----------------
eugenis wrote:
> this can affect scudo performance.
@cryptoad 


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D73557/new/

https://reviews.llvm.org/D73557





More information about the llvm-commits mailing list