[PATCH] D35704: added reset feature to dfsan

Farah Hariri via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jul 28 11:23:12 PDT 2017

farahhariri marked 3 inline comments as done.
farahhariri added inline comments.

Comment at: lib/dfsan/dfsan.cc:179
+  // reset label count
+  atomic_store(&__dfsan_last_label, 0, memory_order_relaxed);
kcc wrote:
> farahhariri wrote:
> > kcc wrote:
> > > Add some code to check-fail in case __dfsan_last_label has changed (i.e. to check that no other threads are messing around)
> > > 
> > > Then, add a test with threads that will trigger that check-fail.
> > > Then, add a test with threads that will trigger that check-fail.
> > 
> > That means I will have to add a flaky test that sometimes passes and sometimes fails.
> > I cannot guarantee that the scheduler will switch context between the atomic store and 
> > the check-fail to another thread, and then switch back to the check-fail. That's the only
> > way to guarantee it will fail..
> You can create a test that runs a very long loop in a thread and thus guarantee that the test will crash 9999999999999999 our of 100000000000000 times. 
I tried that and let it run for 12+ hours and could not trigger the assertion after the atomic store to fail. But what I did is control the thread scheduling from the test and make an assertion in that test fail (check the update).


More information about the llvm-commits mailing list