Both the mpi-type-mismatch and mpi-buffer-deref check make use of a static MPIFunctionClassifier object.
This causes issue as the classifier is initialized with the first ASTContext that produces a match.
If the check is enabled on multiple translation units in a single clang-tidy process, this classifier won't be reinitialized for each TU. I'm not an expert in the MPIFunctionClassifier but I'd imagine this is a source of UB.
It is suspected that this bug may result in the crash caused here: https://bugs.llvm.org/show_bug.cgi?id=48985. However even if not the case, this should still be addressed.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
LGTM, thanks!
clang-tools-extra/clang-tidy/mpi/BufferDerefCheck.cpp | ||
---|---|---|
29–30 | This is racy, but I don't think we support running multiple checks in parallel, do we? |
clang-tools-extra/clang-tidy/mpi/BufferDerefCheck.cpp | ||
---|---|---|
29–30 | This isn't racy as one instance of a check will only ever run on one thread. |
clang-tools-extra/clang-tidy/mpi/BufferDerefCheck.cpp | ||
---|---|---|
29–30 | I was thinking if the check gets run multiple times in parallel on different source files (e.g., someone downstream who incorporates the checks as a library in a creative way rather than runs clang-tidy as a command line tool). But yeah, I'm not worried about it as I don't think we support that sort of thing. |
clang-tools-extra/clang-tidy/mpi/BufferDerefCheck.cpp | ||
---|---|---|
29–30 | Plenty of other checks hold state that is mutated in the check callback, so if this is a race, all the other checks that mutate state in the callbacks will also have a race. |
This is racy, but I don't think we support running multiple checks in parallel, do we?