Thread leak using BuildLauncher in Gradle 2.13

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. buildLauncher.run() // ActiveThreads: 3
  4. pconn.close() // ActiveThreads: 2

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

Can you see what the threads are doing?

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

I could create a minimalistic sample project to reproduce the issue: https://github.com/lkishalmi/gradle-thread-leak
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).

Found the root cause.A possible fix: https://github.com/lkishalmi/gradle/commit/0b1f80a632209bf583cbbbe0e282f21dac42bedc

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

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?

Just for the record the thread on gradle-dev: https://groups.google.com/forum/#!topic/gradle-dev/y-H3urmeTqg

I have filed GRADLE-3448 for this