Skip to content
  1. Mar 01, 2012
  2. Feb 29, 2012
    • Anna Zaks's avatar
      [analyzer] Malloc: A pointer might escape through CFContainers APIs, · e0c03cab
      Anna Zaks authored
      funopen, setvbuf.
      
      Teach the checker and the engine about these APIs to resolve malloc
      false positives. As I am adding more of these APIs, it is clear that all
      this should be factored out into a separate callback (for example,
      region escapes). Malloc, KeyChainAPI and RetainRelease checkers could
      all use it.
      
      llvm-svn: 151737
      e0c03cab
  3. Feb 28, 2012
  4. Feb 25, 2012
    • Anna Zaks's avatar
      [analyzer] Malloc: reason about the ObjC messages and C++. · 7ac344a4
      Anna Zaks authored
      Assume none of the ObjC messages defined in system headers free memory,
      except for the ones containing 'freeWhenDone' selector. Currently, just
      assume that the region escapes to the messages with 'freeWhenDone'
      (ideally, we want to treat it as 'free()').
      
      For now, always assume that regions escape when passed to C++ methods.
      
      llvm-svn: 151410
      7ac344a4
  5. Feb 23, 2012
    • Anna Zaks's avatar
      [analyzer] Malloc: unique leak reports by allocation site. · df901a44
      Anna Zaks authored
      When we find two leak reports with the same allocation site, report only
      one of them.
      
      Provide a helper method to BugReporter to facilitate this.
      
      llvm-svn: 151287
      df901a44
    • Anna Zaks's avatar
      [analyzer] Invalidate the region passed to pthread_setspecific() call. · 07de9c12
      Anna Zaks authored
      Make this call an exception in ExprEngine::invalidateArguments:
      'int pthread_setspecific(ptheread_key k, const void *)' stores
      a value into thread local storage. The value can later be retrieved
      with 'void *ptheread_getspecific(pthread_key)'. So even thought the
      parameter is 'const void *', the region escapes through the
      call.
      
      (Here we just blacklist the call in the ExprEngine's default
      logic. Another option would be to add a checker which evaluates
      the call and triggers the call to invalidate regions.)
      
      Teach the Malloc Checker, which treats all system calls as safe about
      the API.
      
      llvm-svn: 151220
      07de9c12
  6. Feb 22, 2012
  7. Feb 20, 2012
  8. Feb 17, 2012
  9. Feb 16, 2012
  10. Feb 15, 2012
  11. Feb 14, 2012
    • Anna Zaks's avatar
      [analyzer] Make Malloc Checker optimistic in presence of inlining. · 3d34834b
      Anna Zaks authored
      (In response of Ted's review of r150112.)
      
      This moves the logic which checked if a symbol escapes through a
      parameter to invalidateRegionCallback (instead of post CallExpr visit.)
      
      To accommodate the change, added a CallOrObjCMessage parameter to
      checkRegionChanges callback.
      
      llvm-svn: 150513
      3d34834b
    • Anna Zaks's avatar
      [analyzer] Malloc Checker: realloc: add dependency between the symbols · ad01ef5f
      Anna Zaks authored
      in realloc map. 
      
      If there is no dependency, the reallocated ptr will get garbage
      collected before we know that realloc failed, which would lead us to
      missing a memory leak warning.
      
      Also added new test cases, which we can handle now.
      Plus minor cleanups.
      
      llvm-svn: 150446
      ad01ef5f
  12. Feb 13, 2012
    • Anna Zaks's avatar
      [analyzer] Malloc Checker: realloc: correct the way we are handing the · 8fd0f2a6
      Anna Zaks authored
      case when size is 0.
      
      llvm-svn: 150412
      8fd0f2a6
    • Anna Zaks's avatar
      [analyzer] Malloc checker: rework realloc handling: · d56c8794
      Anna Zaks authored
      1) Support the case when realloc fails to reduce False Positives. (We
      essentially need to restore the state of the pointer being reallocated.)
      
      2) Realloc behaves differently under special conditions (from pointer is
      null, size is 0). When detecting these cases, we should consider
      under-constrained states (size might or might not be 0). The
      old version handled this in a very hacky way. The code did not
      differentiate between definite and possible (no consideration for
      under-constrained states). Further, after processing each special case,
      the realloc processing function did not return but chained to the next
      special case processing. So you could end up in an execution in which
      you first see the states in which size is 0 and realloc ~ free(),
      followed by the states corresponding to size is not 0 followed by the
      evaluation of the regular realloc behavior.
      
      llvm-svn: 150402
      d56c8794
  13. Feb 12, 2012
  14. Feb 11, 2012
  15. Feb 10, 2012
  16. Feb 09, 2012
  17. Feb 08, 2012
  18. Feb 05, 2012
  19. Feb 04, 2012
  20. Jan 26, 2012
  21. Jan 17, 2012
Loading