During the investigation of what was initially suspected to be a non-termination bug in the url90b6689baa_adsonrocha_PD321_tgz-pJ8-MyFuzzyLiteClassJ8 project from the NJR dataset, it was discovered that the issue may actually be exponential growth in complexity rather than non-termination. This behavior occurs due to an unchecked accumulation of obligations to track across multiple control-flow paths when the bailout check MustCallConsistencyAnalyzer::shouldTrackInvocationResult is absent.
Execute the reproducing unit test tests/ainfer-resourceleak/non-annotated/FuzzyEngine.java within the ainfer-resourceleak test suite, noting the out-of-memory error that occurs without the proposed modifications, highlighting the unchecked growth in resource consumption.
Fix
The MustCallConsistencyAnalyzer has a bail-out check before tracking obligations using the shouldTrackInvocationResult method. The original method was designed primarily for MustCall consistency checks and did not accommodate the unique requirements of resource leak inference.
The original method does not track the invocation result in these cases:
Constructor Calls: Skips tracking for this() or super() constructor calls.
MustCallAlias Annotations: Omits tracking when the method’s return type is MustCallAlias and corresponds to an owning field.
Non-owning Return Types: Avoids tracking for methods annotated with NotOwning or methods that have no return type.
For example, consider the following code snippet:
@InheritableMustCall("a")
private class MCASuperClass {
final @Owning Foo f;
@MustCallAlias MCASuperClass(@MustCallAlias Foo foo) {
this.f = foo;
}
public void a() {
f.a();
}
}
private class MCASuperCall extends MCASuperClass {
MCASuperCall(Foo foo) {
super(foo);
}
}
In this scenario, if obligations for the super(foo) call are not tracked, then the must-call inference cannot infer that the parameter Foo foo and the constructor are resource aliases. This failure results in the inability to infer the @MustCallAlias annotation correctly for the MCASuperCall, leading to potential resource management issues.
To rectify this, a new parameter isMustCallInference was added to the shouldTrackInvocationResult method. This parameter allows the method to adapt its behavior based on the context—skipping tracking where safe in general cases but enforcing it in resource leak scenarios to ensure accurate management of obligations.
Description
During the investigation of what was initially suspected to be a non-termination bug in the
url90b6689baa_adsonrocha_PD321_tgz-pJ8-MyFuzzyLiteClassJ8project from the NJR dataset, it was discovered that the issue may actually be exponential growth in complexity rather than non-termination. This behavior occurs due to an unchecked accumulation of obligations to track across multiple control-flow paths when the bailout checkMustCallConsistencyAnalyzer::shouldTrackInvocationResultis absent.Steps to Reproduce
url90b6689baa_adsonrocha_PD321_tgz-pJ8-MyFuzzyLiteClassJ8project from the NJR dataset, wit h resourceleak inference enabled. Source: url90b6689baa_adsonrocha_PD321_tgz-pJ8-MyFuzzyLiteClassJ8.ziptests/ainfer-resourceleak/non-annotated/FuzzyEngine.javawithin theainfer-resourceleaktest suite, noting the out-of-memory error that occurs without the proposed modifications, highlighting the unchecked growth in resource consumption.Fix
The
MustCallConsistencyAnalyzerhas a bail-out check before tracking obligations using theshouldTrackInvocationResultmethod. The original method was designed primarily for MustCall consistency checks and did not accommodate the unique requirements of resource leak inference.The original method does not track the invocation result in these cases:
this()orsuper()constructor calls.MustCallAliasand corresponds to an owning field.NotOwningor methods that have no return type.For example, consider the following code snippet:
In this scenario, if obligations for the
super(foo)call are not tracked, then the must-call inference cannot infer that the parameterFoo fooand the constructor are resource aliases. This failure results in the inability to infer the@MustCallAliasannotation correctly for theMCASuperCall, leading to potential resource management issues.To rectify this, a new parameter
isMustCallInferencewas added to theshouldTrackInvocationResultmethod. This parameter allows the method to adapt its behavior based on the context—skipping tracking where safe in general cases but enforcing it in resource leak scenarios to ensure accurate management of obligations.CF Invocation Environment