balazske added a comment.
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 to the `pthread_mutex_destroy` call.
================
Comment at: clang/lib/StaticAnalyzer/Checkers/PthreadLockChecker.cpp:290-304
// Existence in DestroyRetVal ensures existence in LockMap.
// Existence in Destroyed also ensures that the lock state for lockR is
either
// UntouchedAndPossiblyDestroyed or UnlockedAndPossiblyDestroyed.
assert(lstate->isUntouchedAndPossiblyDestroyed() ||
lstate->isUnlockedAndPossiblyDestroyed());
ConstraintManager &CMgr = state->getConstraintManager();
----------------
NoQ wrote:
> ASDenysPetrov wrote:
> > I'm just wondering, did you think about such way of fixing?
> This involves keeping dead regions in the program state. I'd be pretty
> worried about it.
This was my first idea but did not like it because state is not cleaned up
correctly. (And `LockMap` contains data about unaccessible mutex.)
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D98504/new/
https://reviews.llvm.org/D98504
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
