[PATCH] D98504: [clang][Checkers] Fix PthreadLockChecker state cleanup at dead symbol.
Balázs Kéri via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Tue Mar 16 01:08:36 PDT 2021
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
More information about the cfe-commits
mailing list