MongoDB | 2543258

Info

It appears that there are some cases where TSAN can fail to restore a stack and thus that non-collected stack cannot be matched against our TSAN suppressions, in particular for the WT suppressions. We should figure out if we can ensure the stack is always restored successfully.

Top User Comments

xgen-internal-githook commented on Wed, 17 Jan 2024 19:56:31 +0000: Author: {'name': 'Alexander Neben', 'email': 'alex.neben@mongodb.com', 'username': 'IamXander'} Message: SERVER-84759 Changed the TSAN config options to increase history_size (#18045) GitOrigin-RevId: baff19f7e72b6c7ce745385f6fc9f330a5bb24bc Branch: master https://github.com/mongodb/mongo/commit/cce887135a3023cdb637e0a5d3501a4fa0b8a008 max.hirschhorn@10gen.com commented on Thu, 11 Jan 2024 15:06:17 +0000: I'd be curious if we could get a complete stack by adjusting the history_size option: If you intermittently see race reports where one stack is missing with a failed to restore the stack message, this can indicate that a suppression is partially covering the race you are seeing. Any race where only one of the two stacks is matched by a runtime suppression will show up if that particular stack fails to symbolize for some reason. The usual solution is to search the suppressions for potential candidates and disable them temporarily to check if your race report now becomes mostly consistent. However, there are other reasons for broken TSan stacks, in particular if they are not intermittent. See also the history_size parameter in the TSan flags. https://firefox-source-docs.mozilla.org/tools/sanitizer/tsan.html#intermittent-broken-stacks

Steps to Reproduce