Thread leak using BuildLauncher in Gradle 2.13

(Laszlo Kishalmi) #1

I’m writing my own NetBeans plugin for Gradle. Today I’ve tried to upgrade the tooling API from 2.12 to 2.13 (usually it is painless replacing jars.) Though I see something “strange” now.
Some background: NetBeans executes task in separate thread groups and marks task finished when all the threads are finished in the group. I have the following flow (simplified):

  1. pconn = conn.getProjectConnection() // ActiveThreads: 1
  2. config build launcher from pconn // ActiveThreads: 1
  3. // ActiveThreads: 3
  4. pconn.close() // ActiveThreads: 2

So when the flow finishes I have still 1 thread active in the group.

(Sterling Greene) #2

Can you see what the threads are doing?

Do you have an example/standalone case that reproduces this?

(Laszlo Kishalmi) #3

I could create a minimalistic sample project to reproduce the issue:
So this happens only with Gradle 2.13 and setColoredOutput(true) on BuildLauncher. It seems to be completely independent from the used tooling API (so using 2.12 tooling API and requesting 2.13 Gradle execution reveals this problem).

(Laszlo Kishalmi) #4

Found the root cause.A possible fix:

I’m arranging the paperwork for contribution, to create a PR…

(Sterling Greene) #5

Thanks, I thought it could be something related to that area.

I’m not completely familiar with that area of the code, but one question I have with timing out the console renderer thread is if it might cause a perverse create-thread, render, destroy-thread, create-thread, render… cycle when there’s very little output. Potentially the executor needs to be tied into a service that’s stopped when the build stops.

Could you send an email to the gradle-dev list?

(Laszlo Kishalmi) #6

Just for the record the thread on gradle-dev:!topic/gradle-dev/y-H3urmeTqg

(Eric Wendelin) #7

I have filed GRADLE-3448 for this