Commit Graph

6 Commits

Author SHA1 Message Date
Artem Dergachev 134faae042 [analyzer] CStringChecker: Improve warning messages.
Differential Revision: https://reviews.llvm.org/D71321
2019-12-11 11:22:36 -08:00
George Karpenkov 70ec1dd14d [analyzer] Do not run visitors until the fixpoint, run only once.
In the current implementation, we run visitors until the fixed point is
reached.
That is, if a visitor adds another visitor, the currently processed path
is destroyed, all diagnostics is discarded, and it is regenerated again,
until it's no longer modified.
This pattern has a few negative implications:

 - This loop does not even guarantee to terminate.
   E.g. just imagine two visitors bouncing a diagnostics around.
 - Performance-wise, e.g. for sqlite3 all visitors are being re-run at
   least 10 times for some bugs.
   We have already seen a few reports where it leads to timeouts.
 - If we want to add more computationally intense visitors, this will
   become worse.
 - From architectural standpoint, the current layout requires copying
   visitors, which is conceptually wrong, and can be annoying (e.g. no
   unique_ptr on visitors allowed).

The proposed change is a much simpler architecture: the outer loop
processes nodes upwards, and whenever the visitor is added it only
processes current nodes and above, thus guaranteeing termination.

Differential Revision: https://reviews.llvm.org/D47856

llvm-svn: 335666
2018-06-26 21:12:08 +00:00
Artem Dergachev 95f9a68b1f [analyzer] Track null or undef values through pointer arithmetic.
Pointer arithmetic on null or undefined pointers results in null or undefined
pointers. This is obvious for undefined pointers; for null pointers it follows
from our incorrect-but-somehow-working approach that declares that 0 (Loc)
doesn't necessarily represent a pointer of numeric address value 0, but instead
it represents any pointer that will cause a valid "null pointer dereference"
issue when dereferenced.

For now we've been seeing through pointer arithmetic at the original dereference
expression, i.e. in bugreporter::getDerefExpr(), but not during further
investigation of the value's origins in bugreporter::trackNullOrUndefValue().
The patch fixes it.

Differential Revision: https://reviews.llvm.org/D45071

llvm-svn: 328896
2018-03-30 19:27:42 +00:00
Artem Dergachev d85a994ca6 [analyzer] Fix an outdated comment in a test. NFC.
llvm-svn: 314298
2017-09-27 10:59:06 +00:00
Artem Dergachev 8c80061535 [analyzer] Match more patterns in bugreporter::getDerefExpr() API.
This function can now track null pointer through simple pointer arithmetic,
such as '*&*(p + 2)' => 'p' and so on, displaying intermediate diagnostic pieces
for the user to understand where the null pointer is coming from.

Differential Revision: https://reviews.llvm.org/D37025

llvm-svn: 314290
2017-09-27 09:50:45 +00:00
Artem Dergachev 2064e82277 [analyzer] Fix and refactor bugreporter::getDerefExpr() API.
This API is used by checkers (and other entities) in order to track where does
a value originate from, by jumping from an expression value of which is equal
to that value to the expression from which this value has "appeared". For
example, it may be an lvalue from which the rvalue was loaded, or a function
call from which the dereferenced pointer was returned.

The function now avoids incorrectly unwrapping implicit lvalue-to-rvalue casts,
which caused crashes and incorrect intermediate diagnostic pieces. It also no
longer relies on how the expression is written when guessing what it means.

Fixes pr34373 and pr34731.

rdar://problem/33594502

Differential Revision: https://reviews.llvm.org/D37023

llvm-svn: 314287
2017-09-27 09:33:37 +00:00