[cfe-commits] Patch: Initial improvements to PthreadLockChecker

[Ted Kremenek]

On May 9, 2011, at 4:38 PM, Rui Paulo wrote:

> Hi,
> 
> On May 9, 2011, at 4:09 PM, Ted Kremenek wrote:
> 
>> 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).
> 
> 
> Oh, right. The role of lockHistory is to track all the locks that we haven't yet unlocked. The current "state" also does this, but I don't think it keeps an order. I'll have to investigate further. It would be great if I didn't need to add anything to GRState. I'll also work on the test cases on my next opportunity.

You can possibly use an ImmutableList to track lockset ordering (if ordering matters), and use the ImmutableList as the lockset data in GRState.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20110509/9ee75a8c/attachment.html>