[cfe-commits] unix.Malloc static checker improvement: memory.LeakPtrValChanged

[Branden Archer]

I am trying to catch up to your discussion.

I debugged the examples. The callback is called in both cases.
>
> In the second case, we correctly determine that the pointer is being freed.
>
> In the first case, we are not as precise as we could be. We decide that
> the pointer escapes, when 'data' is passed to 'free'. This is part of
> general pessimistic logic, which decides that everything accessible though
> a pointer passed to a function can escape. In this case, we could have
> added more logic to assume that 'free' does not invalidate any pointers. In
> order to do this, we would need to extend the pointerEscapes callback with
> a bool that let's us know if the invalidation is direct or not. Currently,
> we always set Call to NULL, when the invalidation is indirect.
>
>
Oops. You are correct, the callback is being called for both cases. My
mistake.

I am observing that the callback is unable to determine what type of
non-function call based escape has occurred. For example, the second case
is one example:

  int * data = malloc(sizeof(int)*2);
  data += 1;
  free(data);

For that example, I am assuming the callback is being invoked when the
pointer is being changed, but before it is passed to a function. Or maybe
it is occurring when free is being called with an invalid pointer. The
callback does not mention a function, setting Call to NULL, so I am not
sure. Another example that results in a NULL Call is passing data to a
global structure. Passing the pointer to a global structure is quite fine,
but it is indistinguishable from the problem case I am interested in
detecting in example 2.


> Free is special but neither the MallocChecker nor the callback are dealing
> with it.
>
> - The callback could pass non-NULL Call and a special flag saying that the
> invalidation is not direct.
> - The malloc could check if Call is to 'free' and never act upon a pointer
> escape if it is. This could probably be generalized for other functions we
> know about. Ex, it's not malloc checker or 'free' specific - we always know
> that 'free' could only touch the argument. It might be better to find a
> more general solution for this.
>

It is not clear to me in which cases the callback will be invoked when the
escape is not due to a function call. That is, what is the difference
between a 'direct' and 'indirect' invalidation.

I think that the solution you propose may work. That is, passing a non-NULL
Call and a flag (to distinguish example 2 from other situations). For my
curiosity, what are some examples where the Call would still be NULL, and
would the value of the flag matter in such a case?

The invalidation does happen (same as before). However, ideally, we would
> not invalidate and report a leak in example 1.
>

What criteria is being used to determine if a pointer is to be invalidated?

- Branden
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130102/140369bf/attachment.html>