[compiler-rt] [Apple][RTSan] Realtime sanitizers are failing in Apple CI (PR #124873)

[Chris Apple via llvm-commits]

================
@@ -170,23 +170,23 @@ TEST(TestRtsan, CopyingALambdaWithLargeCaptureDiesWhenRealtime) {
   ExpectNonRealtimeSurvival(Func);
 }
 
-TEST(TestRtsan, AccessingALargeAtomicVariableDiesWhenRealtime) {
-  std::atomic<float> small_atomic{0.0f};
-  ASSERT_TRUE(small_atomic.is_lock_free());
-  RealtimeInvoke([&small_atomic]() {
-    float x = small_atomic.load();
-    return x;
-  });
-
-  std::atomic<std::array<float, 2048>> large_atomic;
-  ASSERT_FALSE(large_atomic.is_lock_free());
-  auto Func = [&]() {
-    std::array<float, 2048> x = large_atomic.load();
-    return x;
-  };
-  ExpectRealtimeDeath(Func);
-  ExpectNonRealtimeSurvival(Func);
-}
+// TEST(TestRtsan, AccessingALargeAtomicVariableDiesWhenRealtime) {
+//   std::atomic<float> small_atomic{0.0f};
+//   ASSERT_TRUE(small_atomic.is_lock_free());
+//   RealtimeInvoke([&small_atomic]() {
+//     float x = small_atomic.load();
+//     return x;
+//   });
+
+//   std::atomic<std::array<float, 2048>> large_atomic;
+//   ASSERT_FALSE(large_atomic.is_lock_free());
----------------
cjappl wrote:

To explain what is going on here (just being explicit so you have as much info as possible, you may know any/all of this).

Small types which are made atomics don't need locks, they rely on arch specific instructions. Luckily for us real-time programmers, C++ standard added the `.is_lock_free` assertion so we could sanity check ourselves before using these in timing critical code.

The first half of these test determines that a basic float may be used atomically without an underlying lock happening, we don't intercept anything and don't die.

The second half test uses a mega 2048 float buffer, which cannot be atomically updated without a lock (on any arch I know of). We then test that we intercept the lock call that happens implicitly under the hood. On my mac this intercepts a pthread_mutex_lock I believe.

This passes on my mac, at least, but perhaps Apple changed the internal implementation of the STL to use a different type of lock we don't currently intercept? That fix would be easy enough to do, we could just add the new call into our interceptors. 

If you have found some way to make an atomic update of 2048 floats at once with NO LOCKS, please share the secret sauce 👀  

https://github.com/llvm/llvm-project/pull/124873