[cfe-dev] [analyzer] Summary IPA thoughts

[Gábor Horváth via cfe-dev]

On 31 March 2016 at 14:30, Artem Dergachev <dergachev.a at samsung.com> wrote:

> Hello,
>
> Yeah, there's one particular known-issue with aliasing, which i mentioned
> earlier (http://lists.llvm.org/pipermail/cfe-dev/2015-October/045704.html
> ):
>

Oh, I see. I just started to catch up with the conversation and did not
reach that point yet.


>
>    int a;
>    void foo(int *x, int *y) {
>      *x = 0;
>      *y = 1;
>    }
>    void bar() {
>      foo(&a, &a);
>      clang_analyzer_eval(a); // expected-warning{{TRUE}}
>    }
>
> Here we may randomly get TRUE or FALSE, kind of race condition.
>
> We didn't fix it yet, and it can be fixed by adding timestamps to stores,
> i.e. which bind was earlier.
>
> With timestamps, i think the store would be fine.
>

I think that timestamps might not be a general solution to this problem,
see the next inline response. But as a side not, do you plan to use
timestamps to use this problem:

  void bar(int *b) {
    foo(b); // [1] calling foo()
  }
  void foo(int *a) {
    *a = 0;
    if (a == 0) {
      // [2] warn: null-dereference
    }
  }

Or is this solved already? What did you do about this in that case?


> On the other hand, i don't think that there are other places that
> explicitly rely on assuming different symbols to represent *different*
> values. It's only true for the store, which expects different base-regions
> to non-overlap, even when the regions are symbolic. Say, the constraint
> manager, upon encountering "if (a == b)", should split the state (we did
> enable SymSymExpr for this to work), rather than produce always-false.
>

How did you achieve this? For example:

   int a;
   void foo(int *x, int *y) {
      int a;
      int *b = &a;
      if (x == y)  { } // I expect this to split the state.
      if (b == &a) {} // I expect this not to split the state
   }
   void bar() {
     foo(&a, &a);
   }

Does this work as expected?



>
> And then actualization can take care of the rest. Say the checker, upon
> encountering, say, "fclose(f1); fclose(f2);" and then later, when applying
> the summary, finding out that f1 and f2 is the same descriptor, would
> detect the problem upon actualization of the respective symbols to the same
> symbol. Or the store would correctly merge bindings to different
> sub-regions of aliased regions even if they were not aliased outside the
> context.
>

I think I would prefer a way to do this automatically instead of making
checker writers consider aliasing explicitly. But I may misunderstood your
point.


>
> So, apart from the issues that boil down to the example above, i'm not
> instantly aware of aliasing problems yet.
>
> On 31.03.2016 14:37, Gábor Horváth wrote:
>
>> Hi!
>>
>> I was thinking about the actualization process that you are describing
>> here, and I think there might be some issues with it. As far as I
>> remember, when you analyze a function without context the analyzer
>> assumes that none of the arguments are aliased. So only those paths will
>> be available in the ExpoldedGraph that does not imply aliasing. This way
>> you can both loose coverage or take impossible branches. What do you
>> think?
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160331/581f2370/attachment.html>