It is possible that an entry in 'DestroyRetVal' lives longer
than an entry in 'LockMap' if not removed at checkDeadSymbols.
The added test case demonstrates this.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Hmm this probably even deserves a warning? Like, the mutex goes out of scope but we don't know whether we've successfully destroyed it? Even if we perform the check later, we can't do anything about it anymore? (not sure how bad it is in practice)
clang/lib/StaticAnalyzer/Checkers/PthreadLockChecker.cpp | ||
---|---|---|
290–304 | This involves keeping dead regions in the program state. I'd be pretty worried about it. |
Exactly the case is (I think) that the mutex goes out of scope and we have not checked if it was really destroyed. Still the program can check later if it was destroyed (like the if in the test case). A resource leak may be the problem (if destroy failed) so a warning like "possible resource leak if destroy call fails" can be added. The case is detected in checkDeadSymbols that may make adding a good warning more difficult.
clang/lib/StaticAnalyzer/Checkers/PthreadLockChecker.cpp | ||
---|---|---|
290–304 | This was my first idea but did not like it because state is not cleaned up correctly. (And LockMap contains data about unaccessible mutex.) |
I'm just wondering, did you think about such way of fixing?