[cfe-dev] [analyzer] Toning down invalidations?

[Artem Dergachev via cfe-dev]

I was distracted and never got to actually do this, but i still think 
it's a good idea to try out. Your results look very promising, yay. I 
totally agree that systems of mutually-canceling bugs are worth 
untangling even if the amount of false positives temporarily increases.

P.S. A related issue - if i go for this, i'd probably start with 
relaxing the C++ container inlining heuristic, i.e. replacing it with 
visitor-based suppressions, so that to still enjoy the benefits of inlining.

P.P.S. Mildly related - i noticed that it shouldn't be all that hard to 
model extents of bindings within RegionStore, so that bindings to 
sub-structures didn't overwrite bindings to super-structures simply 
because they have the same base region and the same offset. The only 
problem here is to model extents of *integers* because we don't 
represent casts as part of SymbolRefs. All other sorts of SVals have 
well-defined extents (including, say, lazy compound values).

P.P.P.S. Not really related - just wanted to share an example of a 
curious false positive due to *lack* of invalidation that i've seen 
recently:

int test(int **x) {
  int *y = *x;

  if (*y == 0)
    invalidate(x);

  // should not warn
  return 1 / *y;
}


On 1/22/19 2:44 AM, Gábor Horváth wrote:
> Hi!
>
> What is the status of this?
>
> On Mon, 27 Nov 2017 at 16:24, Artem Dergachev via cfe-dev 
> <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>
>
>     * Invalidating base region when a field is invalidated (as the whole
>     base region is reachable through safe pointer arithmetic).
>
>
> I was doing a little experiment and for the projects I tested the 
> number of results was either the same or increased. Sometimes when the 
> number of results are increased I also lost some results which could 
> be either due to different use of the time budget or ruling out more 
> infeasible paths. The interesting part is, when I turn on refutation, 
> for some projects we can also refute some bugs that we could not 
> earlier.  See the exact numbers [1] and exact bugs [2].
>
> After looking at the new results I found only one FP where the root 
> cause was the less invalidation. But it was an implementation artifact 
> (we should invalidate the super region of a field region, when the 
> super region is a union).
>
> So while having more reports could be annoying, if the root cause of 
> FPs are not likely to be the less invalidation I think it would be 
> worth to actually do less invalidation and have an annotation for 
> cases where we actually need more. In my opinion, currently, when the 
> aggressive invalidation hides some FPs where the root cause is 
> something else, we are only giving ourselves a false sense of quality.
>
> What do you think? Should we pursue this?
>
> [1]: 
> https://docs.google.com/spreadsheets/d/1inqGzSAXHfcP-cJ6BuTAv7QYEpADxRcFyIa4v6bda6c/edit?usp=sharing
> [2]: http://cc.inf.elte.hu:15013/Default/#
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190123/48b68ec4/attachment.html>