[analyzer] Aliasing leads to analyzer failures

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[analyzer] Aliasing leads to analyzer failures

suyash singh via cfe-dev
Hello, I think this case is very similar (if not the same) to case 2 described in this fogbugz case: https://bugs.llvm.org/show_bug.cgi?id=43364

Artem, could you confirm? Any tips on where to get started looking at this one?

clang -cc1 -analyze  -analyzer-checker=core    test.c
test.c:13:7: warning: Branch condition evaluates to a garbage value
  if (p[1])
      ^~~~
1 warning generated.


The reproducer … 
struct S {
  unsigned short val;
};
int main(void)
{
  struct S var = { 0x1122 };
  char *p = (char *)&var;
  int x = 0;
  if (p[0])
    x+=1;
  if (p[1])
    x+=1;
  return x;
}


 

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [analyzer] Aliasing leads to analyzer failures

suyash singh via cfe-dev
Vince and I had a discussion about this in another channel. I am summarizing the relevant information here, so if anybody interested in this mailing list could follow up.

This issue seems to be a known problem, i.e we have a technical debt with handling casts:
Track type information through casts more precisely.
The DynamicTypePropagation checker is in charge of inferring a region's dynamic type based on what operations the code is performing. Casts are a rich source of type information that the analyzer currently ignores.

In the DynamicTypePropagation checker's checkPostStmt(CastExpr*) function there is modeling only for some ObjC casts:
  const auto *OrigObjectPtrType = OriginType->getAs<ObjCObjectPointerType>();
  const auto *DestObjectPtrType = DestType->getAs<ObjCObjectPointerType>();

  if (!OrigObjectPtrType || !DestObjectPtrType)
    return;

Also, this is really suspicious too:
  /// TODO: Handle explicit casts.
  ///       Handle C++ casts.
  ///
  /// Precondition: the cast is between ObjCObjectPointers.  
  ExplodedNode *DynamicTypePropagation::dynamicTypePropagationOnCasts(

Gabor

On Sat, Feb 15, 2020 at 9:56 PM Vince Bridgers via cfe-dev <[hidden email]> wrote:
Hello, I think this case is very similar (if not the same) to case 2 described in this fogbugz case: https://bugs.llvm.org/show_bug.cgi?id=43364

Artem, could you confirm? Any tips on where to get started looking at this one?

clang -cc1 -analyze  -analyzer-checker=core    test.c
test.c:13:7: warning: Branch condition evaluates to a garbage value
  if (p[1])
      ^~~~
1 warning generated.


The reproducer … 
struct S {
  unsigned short val;
};
int main(void)
{
  struct S var = { 0x1122 };
  char *p = (char *)&var;
  int x = 0;
  if (p[0])
    x+=1;
  if (p[1])
    x+=1;
  return x;
}


 
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [analyzer] Aliasing leads to analyzer failures

suyash singh via cfe-dev
No-no, this is most likely https://bugs.llvm.org/show_bug.cgi?id=44114.

 > Any tips on where to get started looking at this one?

In the exploded graph (;

Like, seriously, it's usually very hard to guess what exactly is going
on; bisecting the ill-formed states in the exploded graph dump is the
only reliable way of debugging these things.

On 2/19/20 8:17 PM, Gábor Márton via cfe-dev wrote:

> Vince and I had a discussion about this in another channel. I am
> summarizing the relevant information here, so if anybody interested in
> this mailing list could follow up.
>
> This issue seems to be a known problem, i.e we have a technical debt
> with handling cast <https://clang-analyzer.llvm.org/open_projects.html>s:
>
>     Track type information through casts more precisely.
>     The DynamicTypePropagation checker is in charge of inferring a
>     region's dynamic type based on what operations the code is
>     performing. Casts are a rich source of type information that the
>     analyzer currently ignores.
>
>
> In the DynamicTypePropagation checker's checkPostStmt(CastExpr*)
> function there is modeling only for some ObjC casts:
>   const auto *OrigObjectPtrType =
> OriginType->getAs<ObjCObjectPointerType>();
>   const auto *DestObjectPtrType =
> DestType->getAs<ObjCObjectPointerType>();
>
>   if (!OrigObjectPtrType || !DestObjectPtrType)
>     return;
>
> Also, this is really suspicious too:
>   /// TODO: Handle explicit casts.
>   ///       Handle C++ casts.
>   ///
>   /// Precondition: the cast is between ObjCObjectPointers.
>   ExplodedNode *DynamicTypePropagation::dynamicTypePropagationOnCasts(
>
> Gabor
>
> On Sat, Feb 15, 2020 at 9:56 PM Vince Bridgers via cfe-dev
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     Hello, I think this case is very similar (if not the same) to case
>     2 described in this fogbugz case:
>     https://bugs.llvm.org/show_bug.cgi?id=43364.
>
>     Artem, could you confirm? Any tips on where to get started looking
>     at this one?
>
>     clang -cc1 -analyze -analyzer-checker=core    test.c
>     test.c:13:7: warning: Branch condition evaluates to a garbage value
>       if (p[1])
>           ^~~~
>     1 warning generated.
>
>
>     The reproducer …
>     struct S {
>       unsigned short val;
>     };
>     int main(void)
>     {
>       struct S var = { 0x1122 };
>       char *p = (char *)&var;
>       int x = 0;
>       if (p[0])
>         x+=1;
>       if (p[1])
>         x+=1;
>       return x;
>     }
>
>
>
>     _______________________________________________
>     cfe-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev