version 3.3.1 doesn't properly terminate on error in SBT

[nikiforo]

build.sbt

ThisBuild / scalaVersion := "2.13.7"
ThisBuild / organization := "org.example"

val commonSettings = Seq(
  version := "0.0.1",
  scalacOptions ++= Seq("-deprecation", "-Xfatal-warnings")
)

val root = (project in file("."))
  .settings(commonSettings)
  .settings(
    name := "ds",
    libraryDependencies += "org.typelevel" %% "cats-effect" % "3.3.1"
  )

Main.scala

object Main extends IOApp.Simple {

  def run: IO[Unit] =
    IO.raiseError(new RuntimeException)
}

% sbt
[info] welcome to sbt 1.5.5 (Oracle Corporation Java 13.0.1)
> run

Expected behavior: IOApp completes with error, sbt is usable
Actual behavior: IOApp completes with error, sbt starts consuming all available CPU(up to 800% on my PC)

After I change ce3 version to 3.3.0 the problem disappears.

[vasilmkd]

I'm pretty sure #2600 is the culprit. I'll investigate. Thanks for the report. Upgrading to 3.3.2 won't help either, just FYI.

[vasilmkd]

CE3 3.3.2 crashes sbt 1.6.x completely using this IOApp.

[djspiewak]

Confirmed this locally. Working on confirming the culprit, though I strongly suspect Vasil's hunch is correct.

[djspiewak]

This is absolutely wild, honestly. Taking a thread dump while the VM is firing up all the cores shows exactly… zero active threads. Like, everything is parked. The only real hint is that the WSTP isn't shutdown, because its worker threads are all still alive (just parked).

[djspiewak]

I think what we're actually seeing here is a bug in sbt. Working around it is going to be very subtle and annoying, because it's effectively requiring us to detect that we're running within sbt, unforked, and then impose a different termination semantic not only on the application but upon the worker threads and runtime.

In the interim, if anyone is hitting this, run / fork := true should work around the issue. As a bonus, forking also works around an unrelated(?) bug in sbt which prevents ctrl-c from properly killing the application.

[nikiforo]

In the interim, if anyone is hitting this, run / fork := true should work around the issue.

In my case it didn't help. I downgraded to 3.3.0

[djspiewak]

@nikiforo Does 3.3.3 resolve the issue? It actually surprises me that run / fork := true doesn't fix it, since the problem is very specific to Sbt's thread cleaner, which in turn only exists in unforked runs.

[nikiforo]

Using > run / fork := true
The code consumes all CPU on sbt v1.5.5 for:

• "org.typelevel" %% "cats-effect" % "3.3.1"
• "org.typelevel" %% "cats-effect" % "3.3.2"

Using > run / fork := true
The code kills sbt v1.6.0 for:

• "org.typelevel" %% "cats-effect" % "3.3.1"
• "org.typelevel" %% "cats-effect" % "3.3.2"
• "org.typelevel" %% "cats-effect" % "3.3.3"

On sbt v1.5.5, ce version "3.3.3" issue is resolved for both > run / fork := true & > run

[vasilmkd]

Sbt 1.6.0 is not actually killed, it just lacks the code to trap System.exit (i.e. it's a feature, not a bug).