Hi Rui, Two comments/questions:
1) Please do not use tabs. Please only use spaces (to follow LLVM coding conventions). 2) What is the role of lockHistory? >From what I can tell, lockHistory is trying to record information about events >along a path, but it is doing so using state in the checker object. This >isn't the right approach. Because the checker can be used to explore multiple >paths in any arbitrary order, all checker state needs to be in GRState. Think >of checkers as memory-less objects that cause state transitions in the >GRState. Checkers can have state, but they are usually used to memoize >computation. Any checker state for tracking the evolution of a bug along a >specific path needs to be encoded in a GRState directly (and then ideally >removed when it is no longer needed). Cheers, Ted On May 8, 2011, at 7:16 PM, Rui Paulo wrote: > Simplified the previous patch a bit and added a new simple LOR check. > > <LockChecker_FirstChecks.diff> > > On May 6, 2011, at 1:03 PM, Rui Paulo wrote: > >> Hi, >> >> The following attached patch adds two locking checks to the static analyzer: >> 1) finds double locking problems >> 2) finds double unlocking problems >> >> I also added a few lines of code so that this checker can be used with >> pthread rw locks and also with xnu locks. >> >> Regards, >> -- >> Rui Paulo >> <LockChecker_FirstChecks.diff>_______________________________________________ >> cfe-commits mailing list >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > > -- > Rui Paulo > > > > _______________________________________________ > cfe-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
