Suppress fence-synchronised dependency reports by default - #4
Merged
Merged
Conversation
clean-dependency-fences exercises oneshot's message handover, crossbeam-epoch 0.9.18's reclamation and glibc freeing a detached thread's TLS block from many threads. Every access is ordered, but not in a way TSan models, so each is reported without suppressions. race-in-dependency-callbacks races in code those dependencies run on the extension's behalf: a message's Drop run by oneshot, a closure deferred to the epoch collector and a thread-local destructor. Those races must stay reported whatever is suppressed. Signed-off-by: nimbrel <[email protected]>
…orts TSan does not model standalone fences and cannot see inside glibc, so oneshot's handover, crossbeam-epoch's reclamation and a detached thread's TLS free were filed as races in the extension and failed runs. Each entry names only the dependency's own function. Where the reported frame is an interceptor, race_top cannot name it, so a reviewed race: entry names a function that runs none of the caller's code. The test checks every entry against synthetic reports: the dependencies' own reports are hidden, races in callbacks they run are not. Signed-off-by: nimbrel <[email protected]>
ci.md lists what the defaults cover and how they stay narrow; limitations.md keeps unknown fence-synchronised dependencies, accesses of yours ordered only by such a fence, and the use-after-free the glibc entry could hide. Signed-off-by: nimbrel <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
TSan does not model standalone fences, so reports lying entirely inside some dependencies' synchronisation were filed as "in your extension" and failed runs with no frame of the extension on either access.
Default suppressions now cover:
oneshot: the sender's write into the message slot and the drop that frees the channel (the receiver orders them with a relaxed load andfence(Acquire)).SealedBagread inpop_if_internal, and freeing a finished thread'sLocalwhiletry_advancewalks the list (0.9.19+ changed these for TSan)._dl_deallocate_tlsfreeing a detached, finished thread's TLS.Each entry is commented with the reason. Where the top frame is an interceptor (
free,memcpy),race_top:cannot target the report, so the entry is arace:naming a function that runs none of the caller's code; a test keeps a reviewed list of those.fixtures/clean/clean-dependency-fencesfails inciandstresswithout the entries and passes with them.fixtures/racy/race-in-dependency-callbacksstill reports races in code those dependencies run for you (a message'sDrop, a deferred closure, a thread-local destructor).docs/limitations.mdstates what the entries cannot see, including that the glibc entry can hide a use-after-free on a finished thread's thread-local reached through an escaped pointer.