[PATCH] D69015: [analyzer] Make ExplodedNode identifiers truly stable.

Artem Dergachev via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Oct 15 19:37:49 PDT 2019


NoQ created this revision.
NoQ added reviewers: dcoughlin, xazax.hun, a_sidorin, rnkovacs, Szelethus, baloghadamsoftware, Charusso.
Herald added subscribers: cfe-commits, dkrupp, donat.nagy, mikhail.ramalho, a.sidorin, szepet.
Herald added a project: clang.

I need this for the demo at the dev meeting ^.^"

Instead of using an allocator-based stable identifier as in D51667 <https://reviews.llvm.org/D51667>, let's make truly stable identifiers. The nodes now identify themselves as 1.,2.,3.,..., etc., which is not only nice to read, but also allows reliably setting conditional breakpoints. Eg., in lldb:

  (lldb) br s -n inlineCall -c 'Pred->Id == 12345'

lets you reliably debug the construction of the `CallEnter` node whose predecessor is node 12345.

You could do a similar trick with the current stable IDs but that worked in ~30% of the cases because of slight indeterminism in how immutable sets and maps are allocated in the bump pointer allocator. Now it's fully reliable.

The `exploded-graph-rewriter` is updated accordingly. Additionally, because in exploded graph dumps we collapse multiple real exploded nodes into a single dumped graph node when they have the same state and the respective sub-graph is linear, i changed it to dump *each* node's identifier near the program point. Additionally, the "sink node" and "bug report attached" messages are also passed one per point rather than once per visible node.

Notice the 1., 2., 3. things on the left:

F10279509: Screen Shot 2019-10-15 at 7.26.37 PM.png <https://reviews.llvm.org/F10279509>

That's how bug/sink notices now look:

F10279512: Screen Shot 2019-10-15 at 7.27.18 PM.png <https://reviews.llvm.org/F10279512>

In the worst case this patch may increase memory usage of the static analyzer by around 1MB per process (if all 225000 nodes are constructed, times 4 bytes per unsigned integer on most architectures; note that only one analysis is kept in memory at a time, so the overhead doesn't add up for multiple exploded graphs). So even though i could have hidden the new feature under `#ifndef NDEBUG`, like the whole graph dumping facility, i don't think it's really worth it; i'd much rather enable graph dumping in noassert builds.


Repository:
  rC Clang

https://reviews.llvm.org/D69015

Files:
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/ExplodedGraph.h
  clang/lib/StaticAnalyzer/Core/BugReporter.cpp
  clang/lib/StaticAnalyzer/Core/ExplodedGraph.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
  clang/test/Analysis/dump_egraph.c
  clang/test/Analysis/exploded-graph-rewriter/checker_messages.dot
  clang/test/Analysis/exploded-graph-rewriter/checker_messages_diff.dot
  clang/test/Analysis/exploded-graph-rewriter/constraints.dot
  clang/test/Analysis/exploded-graph-rewriter/constraints_diff.dot
  clang/test/Analysis/exploded-graph-rewriter/edge.dot
  clang/test/Analysis/exploded-graph-rewriter/environment.dot
  clang/test/Analysis/exploded-graph-rewriter/environment_diff.dot
  clang/test/Analysis/exploded-graph-rewriter/node_labels.dot
  clang/test/Analysis/exploded-graph-rewriter/program_points.dot
  clang/test/Analysis/exploded-graph-rewriter/store.dot
  clang/test/Analysis/exploded-graph-rewriter/store_diff.dot
  clang/test/Analysis/exploded-graph-rewriter/topology.dot
  clang/test/Analysis/exploded-graph-rewriter/trimmers.dot
  clang/utils/analyzer/exploded-graph-rewriter.py

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D69015.225148.patch
Type: text/x-patch
Size: 32291 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20191016/e76b6ca3/attachment-0001.bin>


More information about the cfe-commits mailing list