This is an extension to an already existing alpha-checker which finds the calls to blocking functions inside a critical section. (See that original diff: https://reviews.llvm.org/D21506, and an earlier extension: https://reviews.llvm.org/D29567). In this patch lock_guard and unique_lock support has been added.
Details
- Reviewers
dcoughlin xazax.hun zaks.anna - Commits
- rG9a8c8bf60d16: [analyzer] lock_guard and unique_lock extension for BlockInCriticalSection…
rC316892: [analyzer] lock_guard and unique_lock extension for BlockInCriticalSection…
rL316892: [analyzer] lock_guard and unique_lock extension for BlockInCriticalSection…
Diff Detail
- Repository
- rL LLVM
Event Timeline
Looks good overall, but we should try and extend isCalled if possible.
Also, what is the plan for bringing this checker out of alpha? Turning checkers on by default should be top priority since most users are not exposed to them otherwise!
Thank you!
Anna
lib/StaticAnalyzer/Checkers/BlockInCriticalSectionChecker.cpp | ||
---|---|---|
111 ↗ | (On Diff #100885) | Why isCalled is not used here? Would it be possible coextend it to support CXXConstructorCall? |
lib/StaticAnalyzer/Checkers/BlockInCriticalSectionChecker.cpp | ||
---|---|---|
111 ↗ | (On Diff #100885) | CallDescription objects don't support C++ constructors or Objective-C methods. By the way, we've just noticed that this checker crashes on pretty much any Objective-C code: $ cat test.m #include <Foundation/Foundation.h> void foo() { NSObject *obj = [[NSObject alloc] init]; [obj release]; } $ clang --analyze -Xanalyzer -analyzer-checker -Xanalyzer alpha.unix.BlockInCriticalSection test.m Assertion failed: (getKind() != CE_ObjCMessage && "Obj-C methods are not supported"), function isCalled, file <censored>/llvm/tools/clang/lib/StaticAnalyzer/Core/CallEvent.cpp, line 214. So when you use isCalled(), currently you must ensure that a plain C function is being called. I totally agree that isCalled() should be improved to support various calls - its whole point is removing code duplication, i.e. stuff like initIdentifierInfo(). |
lib/StaticAnalyzer/Checkers/BlockInCriticalSectionChecker.cpp | ||
---|---|---|
111 ↗ | (On Diff #100885) | I suggest extending isCalled with C++ constructors. Another option would be to remove isCalled and all dependencies on it if we do not think it should be used by everyone. @xazax.hun, what do you think? |
lib/StaticAnalyzer/Checkers/BlockInCriticalSectionChecker.cpp | ||
---|---|---|
111 ↗ | (On Diff #100885) | I do agree, handling ObjC methods conservatively in a release build is a good idea. I am in favor of keeping the asserts though. One of the reasons I do like the isCalled abstraction, we do not need to use the mutable keyword in the checkers. It would definitely be good to support C++ methods and constructors. It is not trivial to come up with a good design due to overloading. The CallDescription could accept a list of strings that describes the name of the types of the arguments, but what about type aliases? We might add features as we go, but it might become harder to extend it in the future if we do not have a good design upfront. I think such a "call description" will be useful in the future since similar mechanism would be needed to have API Notes support for C++. |
Ping... While extending isCalled is not a must, this should not crash on the sample ObjC code.