Page MenuHomePhabricator

[GWP-ASan] Implementation of crash handler API.

Authored by hctim on Nov 25 2019, 10:17 AM.



Add API for crash handlers to use, so they don't have to rely on the
mass-printed dumpReport() output.

This also moves the method of termination for internally-detected
(INVALID_FREE, DOUBLE_FREE) errors to a SIGSEGV with some internal state saved,
so we can recover the error later, but still pass handling to a crash handler.

Event Timeline

hctim created this revision.Nov 25 2019, 10:17 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptNov 25 2019, 10:17 AM
Herald added subscribers: llvm-commits, Restricted Project, mgorny, srhines. · View Herald Transcript

Is there a reason you want the API to be such that you can get the 'error string', 'allocation string', and metadata? The first two seem nice, though not especially useful without out the stack traces. The third seems like it might be exposing internals we don't want to expose and potentially lead to versioning issues. Also how does the crash reporter already knows the error type when calling these functions? I think perhaps it would make sense to have a getCrashReport() API that fills out a struct and perhaps having dumpReportInternal() only use the information from that struct to avoid duplicating work/ensuring all information we use is exposed? I may not be familiar enough with your crash handler case to understand the justification for why it is structured this way.




I used to do the same thing as you do here but ended up switching to just setting a global with the bad address and calling __builtin_trap(). You might consider doing the same here as you already set the global and would just need to move the if(pointerIsMine()) in diagnoseErrorInternal() after the check


This would be simpler if it returned a const char* instead of writing to a buffer, and then the code below that snprintf()s into dumpReportInternal() would also be simpler and clearer. This would add some code to getErrorString() but I think that's fine.

hctim planned changes to this revision.Dec 4 2019, 11:19 AM

The third seems like it might be exposing internals we don't want to expose and potentially lead to versioning issues.

Agreed. Marking proposed as this also only really provides an API for in-process - and I'll need to make some changes.

hctim abandoned this revision.Fri, Feb 28, 3:08 PM

Merged in D73557.