Summary:public
Before this diff, the Java frontend was not adding the definition of the inherited interfaces to the type environment, thus failing to answer questions like "does type X implements Closeable". Infer was therefore missing to detect resource leaks when the resource was indirectly implementing Closeable via an intermediate interface.
Reviewed By: sblackshear
Differential Revision: D3067555
fb-gh-sync-id: 86d0760
shipit-source-id: 86d0760
Summary:public
This just simplifies the end-to-end tests for Dividde By Zero to make the debugging easier when this test fails.
Reviewed By: cristianoc
Differential Revision: D2966296
fb-gh-sync-id: 5eaa1b5
shipit-source-id: 5eaa1b5
Summary:
public
The inductive list predicate was not firing during abstraction because of a type mismatch between C and Java. In Java, the second parameter of the `Sil.Sizeof` constructor is always `Sil.Subtype.exact` in C but is `Sil.Subtype.subtypes` in Java. This diff fixes the confution by comparing the `Sil` types only instead of the type expressions.
Reviewed By: jberdine
Differential Revision: D2912493
fb-gh-sync-id: 3f712a8
shipit-source-id: 3f712a8
Summary:
public
Lines other than the first of multi-line comments in non-ocaml files
were flush right instead of aligned.
Reviewed By: jvillard
Differential Revision: D2739752
fb-gh-sync-id: c85f56e
Summary: public
I realized that this code was returning false for `android.content.Context <: android.content.Context`.
Reviewed By: cristianoc
Differential Revision: D2699112
fb-gh-sync-id: 4c01c42
Summary: public
The classes `java.util.zip.{Inflater/Deflater}` where not modelled as resources. In practice, bad memory leak can happen using these classes and forcing the call to `end()` can help to avoid waisting native memory.
Reviewed By: sblackshear
Differential Revision: D2661249
fb-gh-sync-id: 1e33316
Summary: Add possibility of throwing IOException to model of
java.nio.channels.FileChannel.tryLock, and add test case.
public
Reviewed By: cristianoc
Differential Revision: D2658203
fb-gh-sync-id: 9ca9c02
Summary: Add models of the java.nio.channels.FileChannel.tryLock methods which can
return null according to the java docs.
public
Reviewed By: sblackshear, cristianoc
Differential Revision: D2650050
fb-gh-sync-id: ae6c8ce
Summary: public
The context leaks were reported multiple times. If a leaks was found on method `f()` and `g()` calls `f()`, then the same leak was report both in `f()` and in `g()`.
Reviewed By: sblackshear
Differential Revision: D2598110
fb-gh-sync-id: ca90b57
Summary: public
Extends the current activity leak checker to all sort of context leaks.
Reviewed By: sblackshear
Differential Revision: D2572548
fb-gh-sync-id: 9da18e4
Summary: @public Infer previously did not work correctly when a function returns the result of a skip function:
```
retUndef() {
x = undefined();
return x;
}
derefUndef() {
y = retUndef();
y.doSomething(); // Symexec_memory_error here, prevents spec inference
}
```
The problem is that angelic mode did not know to add the return value of `retUndef()` to the footprint.
This diff fixes the problem by adding return values marked with the `Aundef` attribute to the footprint.
This is done lazily (e.g., a value only gets added to the footprint when you try to deref it).
Reviewed By: @jvillard
Differential Revision: D2444929
Summary:
System.getProperty can return null when the property is not found, and expects a non-null argument.
Add models for Infer and Eradicate to reflect that.
Summary: Handler.postDelayed keeps a persistent reference to its Runnable argument that may cause a memory leak if an Activity is reachable from the Runnable.
Summary: The Nullable checker reported FP's when a Nullable field/param was reassigned to a non-Nullable value in the footprint. This diff fixes the problem.
Summary:
When detecting a resource leak, Infer used to raise an Leak exception and then prevent the specs to be computed for the paths containing a leak. This diff prevents resource leak to stop the analysis.
Summary:
Creating a persistent reference to an Activity leads to a nasty form of memory leaks (see http://android-developers.blogspot.com/2009/01/avoiding-memory-leaks.html, https://corner.squareup.com/2015/05/leak-canary.html). There are many ways to create a bad persistent reference to an Activity, but the most obvious one is via a static field.
This diff implements a very simple form of Activity leak checking by inspecting postconditions to see if a subtype of Activity is reachable from a static field (and it reports an error if so). This is a very simple and limited form of leak checking that does not understand the Android lifecycle at all. In particular, if one creates a persistent reference to an Activity and then nulls it out in `onDestroy` (a reasonably common pattern), this approach will wrongly report a bug.