[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