Tracking down unreleased file handles


(Sam Snyder) #1

I’m having a problem with sporadic failures of delete/clean tasks in our build.
Something isn’t giving up its file handles when its done with them. And since the Daemon is long-lived those resources aren’t naturally reclaimed by the OS between gradle invocations.

It could be Gradle itself or, more likely, a poorly written first or third party plugin. But I don’t know how to work backwards from “Unable to delete file” to a line of code somewhere.

Any advice?


(Luke Daley) #2

Hi Sam,

http://file-leak-detector.kohsuke.org/ might point you at the culprit.

LD.


(Sam Snyder) #3

Thanks for the suggestion, Luke!
Using that tool I was able to find out that it’s our invocation of the AspectJ compiler that’s holding the file handles. More investigation is required to fully root cause the issue, but thanks to your pointer I have a starting point.

For the benefit of anyone who might google into this thread, here’s how I used the file-leak-detector tool with Gradle:

  1. Downloaded the file-leak-detector jar to the root directory of our build
  2. Started the Gradle Daemon running with gradlew help
  3. Noted the PID of the Daemon process
  4. Started the leak detector w/ http server on an available port java -jar file-leak-detector-1.8-jar-with-dependencies.jar <pid> http=<port>
  5. Ran gradle build previously observed to hold file handles
  6. Viewed file handle report in web browser on the port specified in step 4, found offending stack trace frames

Thanks again, Luke