Thread race conditions in lldb-mi cause regular failures. Skip rather than xfail as otherwise each one has to wait for timeout.
I tried adding @skipIfFreeBSD on each one as it failed, but the failures are inconsistent and different ones come up on subsequent runs. It seems like it will just be a lot of churn for no real benefit to go that way.
This approach makes it easy to run the lldb-mi tests with +m when we think it's worthwhile without having to back out all of the individual annotations each time.
Fwiw I don't feel strongly either way. Right now it seems there's issues
with lldb-mi such that even disabling them individually now, a new test
that gets added might have the same issue, because the issue is not in the
implementation of a particular test or feature, but of the larger lldb-mi
library. So this would still lead to the possibility that any future test
may also have to be disabled, creating more work than necessary.
Of course, the correct way to deal with this is to prioritize finding and
fixing the underlying race conditions. Presumably they affect not just
Indeed. On FreeBSD we often encounter threading issues earlier or more often than other platforms, for two reasons.
First, our thread library places stricter demands on POSIX compliance of consumers. For example, pthread_rwlock_wrlock and pthread_rwlock_unlock must be called from the same thread, but this was originally violated by LLDB. In practice it seemed to work on OS X and Linux, but did not on FreeBSD (which returns EINVAL from the unlock).
Second, we seem to have wider race windows in certain cases due to differences in scheduling or preemption. Issues that show up under these conditions will also happen on other platforms, perhaps just less frequently.