Table of Contents
Fetching ...

Repairing Leaks in Resource Wrappers

Sanjay Malakar, Michael D. Ernst, Martin Kellogg, Manu Sridharan

TL;DR

Resource leaks in Java often involve user-defined wrappers that hold resources in fields, which bluntly challenges automated repair. Arodnap integrates RLC inference, code transformations, and enhanced RLFixer with field containment analysis to enable sound repairs for wrapper-based leaks, including patch materialization and validation. On the NJR benchmark, Arodnap achieves a leak-resolution rate of 68%, surpassing the previous 41% by RLFixer alone and 50% with inference added, by effectively handling resources stored in fields and through new repair patterns like pre-close insertion. This work significantly broadens automated repair coverage for real-world resource management patterns and provides an end-to-end pipeline with static/dynamic validation and open-source tooling. The approach offers practical impact by enabling safer, automated fixes for wrapper-based resource leaks in large Java codebases.

Abstract

A resource leak occurs when a program fails to release a finite resource like a socket, file descriptor or database connection. While sound static analysis tools can detect all leaks, automatically repairing them remains challenging. Prior work took the output of a detection tool and attempted to repair only leaks from a hard-coded list of library resource types. That approach limits the scope of repairable leaks: real-world code uses resource wrappers that store a resource in a field and must themselves be closed. This paper makes four key contributions to improve resource leak repair in the presence of wrappers. (1) It integrates inference of resource management specifications into the repair pipeline, enabling extant fixing approaches to reason about wrappers. (2) It transforms programs into variants that are easier to analyze, making inference, detection, and fixing tools more effective; for instance, it makes detection tools report problems closer to the root cause, often in a client of a resource wrapper rather than within the wrapper class itself. (3) A novel field containment analysis reasons about resource lifetimes, enabling repair of more leaks involving resources stored in fields. (4) It introduces a new repair pattern and more precise reasoning to better handle resources stored in non-final fields. Prior work fixed 41% of resource leak warnings in the NJR benchmark suite; our implementation Arodnap fixes 68%.

Repairing Leaks in Resource Wrappers

TL;DR

Resource leaks in Java often involve user-defined wrappers that hold resources in fields, which bluntly challenges automated repair. Arodnap integrates RLC inference, code transformations, and enhanced RLFixer with field containment analysis to enable sound repairs for wrapper-based leaks, including patch materialization and validation. On the NJR benchmark, Arodnap achieves a leak-resolution rate of 68%, surpassing the previous 41% by RLFixer alone and 50% with inference added, by effectively handling resources stored in fields and through new repair patterns like pre-close insertion. This work significantly broadens automated repair coverage for real-world resource management patterns and provides an end-to-end pipeline with static/dynamic validation and open-source tooling. The approach offers practical impact by enabling safer, automated fixes for wrapper-based resource leaks in large Java codebases.

Abstract

A resource leak occurs when a program fails to release a finite resource like a socket, file descriptor or database connection. While sound static analysis tools can detect all leaks, automatically repairing them remains challenging. Prior work took the output of a detection tool and attempted to repair only leaks from a hard-coded list of library resource types. That approach limits the scope of repairable leaks: real-world code uses resource wrappers that store a resource in a field and must themselves be closed. This paper makes four key contributions to improve resource leak repair in the presence of wrappers. (1) It integrates inference of resource management specifications into the repair pipeline, enabling extant fixing approaches to reason about wrappers. (2) It transforms programs into variants that are easier to analyze, making inference, detection, and fixing tools more effective; for instance, it makes detection tools report problems closer to the root cause, often in a client of a resource wrapper rather than within the wrapper class itself. (3) A novel field containment analysis reasons about resource lifetimes, enabling repair of more leaks involving resources stored in fields. (4) It introduces a new repair pattern and more precise reasoning to better handle resources stored in non-final fields. Prior work fixed 41% of resource leak warnings in the NJR benchmark suite; our implementation Arodnap fixes 68%.

Paper Structure

This paper contains 39 sections, 2 equations, 12 figures.

Figures (12)

  • Figure 1: Specification inference makes leaks repairable. With no resource management specification annotations, RLC reports a leak at line 5, where repair is not possible. With added specifications (highlighted in green), RLC reports the leak at line 13 --- where repair is feasible by closing the MyWriter object.
  • Figure 2: Simplified leak repair example from the NJR dataset, benchmark url882f91ec97_WenboCao_Microsoft_Drone, file Generate-DeterminantFromMinor.java. RLFixer cannot repair the original code (\ref{['lst:mot-example-leaky']}). In \ref{['lst:mot-example-fixed']} Arodnap inserts the missing finalizer, which enables inference to infer ownership. RLFixer then eliminates both leaks: one inserting a try-- finally wrapper at lines 25--30 and one by inserting a pre-close on line 9 before the field overwrite.
  • Figure 3: Arodnap's leak-repair pipeline. Dark gray boxes indicate new components we introduced; light gray boxes are existing components we extended; white boxes are existing components we reused.
  • Figure 4: Using a temporary variable for final assignment
  • Figure 5: A resource accessor class uses, but does not own or close, a resource.
  • ...and 7 more figures

Theorems & Definitions (1)

  • Definition 4.2.2.1: Field containment