[cfe-commits] Patch: Initial improvements to PthreadLockChecker

[Ted Kremenek]

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
>> cfe-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
> 
> --
> Rui Paulo
> 
> 
> 
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits