[all-commits] [llvm/llvm-project] 0b2778: [analyzer] Fix StdLibraryFunctionsChecker crash on...

[DonatNagyE via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 0b2778d5e59192331351e082a354843b0e9c1235
      https://github.com/llvm/llvm-project/commit/0b2778d5e59192331351e082a354843b0e9c1235
  Author: DonatNagyE <donat.nagy at ericsson.com>
  Date:   2023-09-14 (Thu, 14 Sep 2023)

  Changed paths:
    M clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp

  Log Message:
  -----------
  [analyzer] Fix StdLibraryFunctionsChecker crash on surprising sink node (#66109)

Recent changes in StdLibraryFunctionsChecker introduced a situation
where the checker sequentially performed two state transitions to add
two separate note tags.

In the unlikely case when the updated state (the variable `NewState`)
was posteriorly overconstrained, the engine marked the node after the
first state transition as a sink to stop the "natural" graph exploration
after that point.

However, in this particular case the checker tried to directly add a
second node, and this triggered an assertion in the `addPredecessor()`
method of `ExplodedNode`.

This commit introduces an explicit `isSink()` check to avoid this crash.
To avoid similar bugs in the future, perhaps it would be possible to
tweak `addTransition()` and ensure that it returns `nullptr` when it
would return a sink node (to unify the two possible error conditions).

This crash was observed in an analysis of the curl project (in a very
long and complex function), and there I validated that this is the root
cause, but I don't have a self-contained testcase that can trigger the
creation of a PosteriorlyOverconstrained node in this situation.