Skip to content
  1. Apr 01, 2012
  2. Mar 30, 2012
  3. Mar 28, 2012
  4. Mar 27, 2012
  5. Mar 26, 2012
  6. Mar 24, 2012
  7. Mar 23, 2012
  8. Mar 22, 2012
  9. Mar 21, 2012
  10. Mar 18, 2012
    • Jordy Rose's avatar
      [analyzer] Mark a failed-realloc's result as an interesting symbol between the... · bf38f20e
      Jordy Rose authored
      [analyzer] Mark a failed-realloc's result as an interesting symbol between the realloc call and the null check, so we get nicer path notes. Fixes a regression introduced by the diagnostic pruning added in r152361.
      
      This is accomplished by calling markInteresting /during/ path diagnostic generation, and as such relies on deterministic ordering of BugReporterVisitors -- namely, that BugReporterVisitors are run in /reverse/ order from how they are added. (Right now that's a consequence of storing visitors in an ImmutableList, where new items are added to the front.) It's a little hacky, but it works for now.
      
      I think this is the best we can do without storing the relation between the old and new symbols, and that would be a hit whether or not there ends up being an error.
      
      llvm-svn: 153010
      bf38f20e
    • Jordy Rose's avatar
      [analyzer] Use a FoldingSet to cache simple RetainSummary instances, rather... · 61c974b4
      Jordy Rose authored
      [analyzer] Use a FoldingSet to cache simple RetainSummary instances, rather than explicitly keeping DoNothing and StopTracking summaries and nothing else.
      
      I tried to test the effects of this change on memory usage and run time, but what I saw on retain-release.m was indistinguishable from noise (debug and release builds). Even so, some caveman profiling showed 101 cache hits that we would have generated new summaries for before (i.e. not default or stop summaries), and the more code we analyze, the more memory we should save.
      
      Maybe we should have a standard project for benchmarking the retain count checker's memory and time?
      
      llvm-svn: 153007
      61c974b4
  11. Mar 17, 2012
  12. Mar 15, 2012
    • Anna Zaks's avatar
      [analyzer] Allow checkers to supply call stack diagnostic hints for the · 1ff57d57
      Anna Zaks authored
      BugVisitor DiagnosticPieces.
      
      When checkers create a DiagnosticPieceEvent, they can supply an extra
      string, which will be concatenated with the call exit message for every
      call on the stack between the diagnostic event and the final bug report.
      (This is a simple version, which could be/will be further enhanced.)
      
      For example, this is used in Malloc checker to produce the ",
      which allocated memory" in the following example:
      
      static char *malloc_wrapper() { // 2. Entered call from 'use'
          return malloc(12);    // 3. Memory is allocated
      }
      
      void use() {
          char *v;
          v = malloc_wrapper(); // 1. Calling 'malloc_wrappers'
              // 4. Returning from 'malloc_wrapper', which allocated memory
      }                         // 5. Memory is never released; potential
      memory leak
      
      llvm-svn: 152837
      1ff57d57
  13. Mar 11, 2012
  14. Mar 10, 2012
  15. Mar 09, 2012
    • Ted Kremenek's avatar
      [analyzer] Implement basic path diagnostic pruning based on "interesting" symbols and regions. · 1e809b4c
      Ted Kremenek authored
      Essentially, a bug centers around a story for various symbols and regions.  We should only include
      the path diagnostic events that relate to those symbols and regions.
      
      The pruning is done by associating a set of interesting symbols and regions with a BugReporter, which
      can be modified at BugReport creation or by BugReporterVisitors.
      
      This patch reduces the diagnostics emitted in several of our test cases.  I've vetted these as
      having desired behavior.  The only regression is a missing null check diagnostic for the return
      value of realloc() in test/Analysis/malloc-plist.c.  This will require some investigation to fix,
      and I have added a FIXME to the test case.
      
      llvm-svn: 152361
      1e809b4c
  16. Mar 08, 2012
    • Anna Zaks's avatar
      Add a basic CallGraph to Analysis. · c000e7ed
      Anna Zaks authored
      The final graph contains a single root node, which is a parent of all externally available functions(and 'main'). As well as a list of Parentless/Unreachable functions, which are either truly unreachable or are unreachable due to our analyses imprecision.
      
      The analyzer checkers debug.DumpCallGraph or debug.ViewGraph can be used to look at the produced graph.
      
      Currently, the graph is not very precise, for example, it entirely skips edges resulted from ObjC method calls.
      
      llvm-svn: 152272
      c000e7ed
  17. Mar 06, 2012
  18. Mar 05, 2012
  19. Mar 03, 2012
  20. Mar 01, 2012
Loading