etorreborre/specs2

Thread leaking regression in 4.13.1

melezov opened this issue · 2 comments

Specs2 4.13.1 has a thread leaking regression that spawns a thread for every test that it runs.
Result of this is CI crashing with OOMs due to eating thousands of threads or hitting other limits of the system (# of threads allowed).

Reproducible example:

// libraryDependencies += "org.specs2" %% "specs2-core" % "4.12.12" % Test // works
// libraryDependencies += "org.specs2" %% "specs2-core" % "4.13.0" % Test // works
libraryDependencies += "org.specs2" %% "specs2-core" % "4.13.1" % Test // leaks threads

Spec:

package com.example

import org.specs2.mutable.Specification

class ThreadTest extends Specification {
  private[this] def threadCount = java.lang.management.ManagementFactory.getThreadMXBean.getThreadCount

  "0" >> { System.err.println(s"0 sees $threadCount threads"); 0 ==== 0 }
  "1" >> { System.err.println(s"1 sees $threadCount threads"); 1 ==== 1 }
  "2" >> { System.err.println(s"2 sees $threadCount threads"); 2 ==== 2 }
  "3" >> { System.err.println(s"3 sees $threadCount threads"); 3 ==== 3 }
  "4" >> { System.err.println(s"4 sees $threadCount threads"); 4 ==== 4 }
  "5" >> { System.err.println(s"5 sees $threadCount threads"); 5 ==== 5 }
  "6" >> { System.err.println(s"6 sees $threadCount threads"); 6 ==== 6 }
  "7" >> { System.err.println(s"7 sees $threadCount threads"); 7 ==== 7 }
  "8" >> { System.err.println(s"8 sees $threadCount threads"); 8 ==== 8 }
  "9" >> { System.err.println(s"9 sees $threadCount threads"); 9 ==== 9 }
}

Reproduced on SBT 1.5/6.x + Scala 2.13.7/8

Oh, forgot to mention - to see the leakage on this minimal repro example run sbt test test test test test or copy the spec to a few files ThreadTest2 ThreadTest3 to see it leak inside a single test run.

Thanks for the report and repro. This is fixed now in 4.13.2