[cfe-dev] [Static Analyzer] temp_object chaos?

Anna Zaks ganna at apple.com
Thu Sep 12 10:48:33 PDT 2013


On Sep 11, 2013, at 2:03 PM, Gábor Kozár <kozargabor at gmail.com> wrote:

> I'm analyzing the following source line:
>  
> auto it = v.begin(); // v is an std::vector<int>
>  
> As far as I'm able to reconstruct what happens using the checker callbacks, it goes somehow like this:
>  - checkPostCall on v.begin(): the call has been interpreted, the result is a lazyCompoundVal with a temp_object within it
>  - checkPostStmt on v.begin(): ProgramState::getSVal() yields the same result as above (the same lazyCompoundVal with the same temp_object within it)
>  - bind: some lazyCompoundVal with a temp_object within it to loc '&it' -- but this lazyCompoundVal and temp_object are different than above!!!
>  - checkPostStmt on v.begin() again: ProgramState::getSVal() yields &it, getting the SVal inside the region gives a lazyCompoundVal with 'it' in it

The last line is probably wrong.. You have "checkPostStmt on v.begin()" twice. Also, can you figure out which AST node is responsible for the bind?

Basically, to understand what is going on better, it would be valuable to match the AST of the statements to the callbacks (you can get the AST with clang -cc1 -ast-dump):
    `-DeclStmt 0x1023e7f00 <line:6:3, col:22>
      `-VarDecl 0x1023cd780 <col:3, col:21> it 'class __gnu_cxx::__normal_iterator<int *, class std::vector<int, class std::allocator<int> > >':'class __gnu_cxx::__normal_iterator<int *, class std::vector<int, class std::allocator<int> > >'
        `-CXXConstructExpr 0x1023e7ec8 <col:13, col:21> 'class __gnu_cxx::__normal_iterator<int *, class std::vector<int, class std::allocator<int> > >':'class __gnu_cxx::__normal_iterator<int *, class std::vector<int, class std::allocator<int> > >' 'void (const class __gnu_cxx::__normal_iterator<int *, class std::vector<int, class std::allocator<int> > > &) throw()' elidable
          `-MaterializeTemporaryExpr 0x1023e7da8 <col:13, col:21> 'const class __gnu_cxx::__normal_iterator<int *, class std::vector<int, class std::allocator<int> > >' lvalue
            `-ImplicitCastExpr 0x1023e7d90 <col:13, col:21> 'const class __gnu_cxx::__normal_iterator<int *, class std::vector<int, class std::allocator<int> > >' <NoOp>
              `-CXXMemberCallExpr 0x1023cd8a0 <col:13, col:21> 'iterator':'class __gnu_cxx::__normal_iterator<int *, class std::vector<int, class std::allocator<int> > >'
                `-MemberExpr 0x1023cd870 <col:13, col:15> '<bound member function type>' .begin 0x1023c66d0
                  `-DeclRefExpr 0x1023cd7d8 <col:13> 'std::vector<int>':'class std::vector<int, class std::allocator<int> >' lvalue Var 0x1023bebc0 'v' 'std::vector<int>':'class std::vector<int, class std::allocator<int> >'


We've looked at implementing these checks before and it is not a simple problem. The issue here is that the iterators are value objects, represented by LazyCompoundVals and SVals, and we do not have any way of persisting/tracking values right now.

Let's start with mapping the results of callbacks to the AST nodes to see if the modeling that we have now makes sense. 

Thanks,
Anna.

>  
> My problem is that I'm unable to implement a checker that would need to track iterator values, as temp_objects just seem to pop and disappear without leaving a trace and without having any followable connection between them.
>  
> Is this working as intended, and if so, how should I approach this? I recall there being an open project for better modelling of C++ temporary objects, is that whose effect I'm seeing here?
>  
> Thanks!
>  
> -- 
> Gábor Kozár -- ShdNx
> kozargabor at gmail.com
>  
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130912/eddef903/attachment.html>


More information about the cfe-dev mailing list