comment

Sources/SentryCrash/Recording/Monitors/SentryCrashMonitor_MachException.c

@@ -527,6 +527,12 @@ setEnabled(bool isEnabled)
         sentrycrashid_generate(g_secondaryEventID);
         g_isEnabled = installExceptionHandler();
     }
+
+    // We don't call uninstallExceptionHandler by intention. Instead of canceling the exception
+    // handler threads and restarting them, we let them run. They won't do anything in
+    // handleExceptions when g_isEnabled is false. Trying to clean them up lead to weird crashes in
+    // tests cause sentrycrashmc_suspendEnvironment and sentrycrashmc_resumeEnvironment call
+    // sentrycrashcm_isReservedThread. Instead of fixing that, we let them run.
 }
 
 static bool

Sources/SentryCrash/Recording/SentryCrash.h

@@ -208,7 +208,9 @@ static NSString *const SENTRYCRASH_REPORT_ATTACHMENTS_ITEM = @"attachments";
 /**
  * It's not really possible to completely uninstall SentryCrash. The best we can do is to deactivate
  * all the monitors, keep track of the already installed monitors to install them again if someone
- * calls install, clear the `onCrash` callback, and stop the SentryCrashCachedData.
+ * calls install, clear the `onCrash` callback, and stop the SentryCrashCachedData. For the
+ * ``SentryCrashMonitorTypeMachException`` we let the exception threads running, but they don't
+ * report anything.
  */
 - (void)uninstall;