This is an archive of the discontinued LLVM Phabricator instance.

Workaround ASAN race condition in future tests by manually joining threads.
AbandonedPublic

Authored by EricWF on Nov 20 2014, 3:48 PM.

Details

Summary

There is a race condition in ASAN where it can perform the leak detection before all detached threads exit and free their resources. This can lead to failures in the future tests.
This patch fixes the race condition my manually joining all threads that are used. This patch should not affect the functionality of the tests.

Diff Detail

Event Timeline

EricWF updated this revision to Diff 16460.Nov 20 2014, 3:48 PM
EricWF retitled this revision from to Workaround ASAN race condition in future tests by manually joining threads..
EricWF updated this object.
EricWF edited the test plan for this revision. (Show Details)
EricWF added reviewers: mclow.lists, danalbert, jroelofs.
EricWF added a subscriber: Unknown Object (MLST).

The ASAN bug has been filed as PR21621.
http://llvm.org/bugs/show_bug.cgi?id=21621

jroelofs edited edge metadata.Nov 20 2014, 4:14 PM

So 4 things:

  • I'm a little out of my comfort zone with this thread stuff... pretty far from my area of expertise
  • Perhaps you missed a few, for example: thread/futures/futures.promise/set_value_at_thread_exit_void.pass.cpp (grep for 'detach' in tests).
  • Doesn't this reduce the test coverage for the thread.detach() method?
  • I *really* *really* don't like the idea of changing tests to push bugs under the rug. It'd be much better to 'XFAIL: asan' these. I have a thought on how to fix asan that I'll add to the PR.

Cheers,

Jon

danalbert edited edge metadata.Nov 20 2014, 4:22 PM

I *really* *really* don't like the idea of changing tests to push bugs under the rug. It'd be much better to 'XFAIL: asan' these. I have a thought on how to fix asan that I'll add to the PR.

Agreed.

Erm, nevermind, my idea won't work (for the record, it was something to do with -Wl,--wrap,atexit). This still makes me uncomfortable.

In D6347#5, @jroelofs wrote:

So 4 things:

  • I'm a little out of my comfort zone with this thread stuff... pretty far from my area of expertise
  • Perhaps you missed a few, for example: thread/futures/futures.promise/set_value_at_thread_exit_void.pass.cpp (grep for 'detach' in tests).

I left those out on purpose since the value should not be set until the thread cleans up and exits. So there should be no race condition.

  • Doesn't this reduce the test coverage for the thread.detach() method?

These tests are not intended to test thread.detach(). detach() should be thoroughly tested elsewhere but I'll double check.

  • I *really* *really* don't like the idea of changing tests to push bugs under the rug. It'd be much better to 'XFAIL: asan' these. I have a thought on how to fix asan that I'll add to the PR.

Me too. The initial response to the PR was that this might not be fixable and we don't want tests that occasionally fail with ASAN. We can't XFAIL these tests because they pass 90% of the time. We could mark them as UNSUPPORTED but then you lose test coverage with ASAN. Since the above changes should not change the functionality of the tests I think this is the best approach.

mclow.lists edited edge metadata.Nov 20 2014, 4:57 PM
In D6347#5, @jroelofs wrote:
  • I *really* *really* don't like the idea of changing tests to push bugs under the rug. It'd be much better to 'XFAIL: asan' these. I have a thought on how to fix asan that I'll add to the PR.

I, too, would much prefer a fix to ASAN, and/or a way to XFAIL them.
[ But I did note that this is an "intermittent failure" under ASAN ]

Lets hold off for a couple of days to see if this can be fixed in ASAN then. Otherwise I don't see another option.

EricWF abandoned this revision.Dec 6 2014, 11:10 AM

Apparently this has been fixed in ASAN! Happily abandoning.