[PATCH] D92415: [GWP-ASan] Fix flaky test on Fuchsia

Mitch Phillips via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Dec 1 13:15:03 PST 2020


hctim added a comment.

In D92415#2426397 <https://reviews.llvm.org/D92415#2426397>, @mcgrathr wrote:

> I'm troubled in two ways.
>
> 1. If this test is polluted by global (TLS) state from prior tests, that seems like a non-hermeticity problem for all these tests.  Should we maybe be using a test fixture with SetUp/TearDown to wipe the global state between tests?

In other environments (both for upstream testing and Android <https://cs.android.com/android/platform/superproject/+/master:external/gwp_asan/Android.bp;drc=97b33726d10616f2531366bb38534bdead7bbb53;l=187>) we run this test in isolation to avoid this problem.

I'm happy with Kostya's solution to spawn a thread, or resetting the TLS in the start of this test (`*gwp_asan::getThreadLocals() = ThreadLocalPackedVariables();`)

> 2. It seems like the code under test actually has semantics that when uninitialized, it will sometimes sample (just rarely).  That seems like a problem to me.  If the initialized state as configured by the environment will be to never do a gwp allocation, then there should never be a window where one is randomly allowed to happen.

There's an uninitialized check in the slow path. We might enter `GPA::allocate()` after `1 << 31` allocations, but we never actually provide a GWP-ASan allocation (it just returns `nullptr`) and we reset the counter to wait another `1 << 31` times before entering the slow path again.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92415



More information about the llvm-commits mailing list