There can be race conditions where we try to interrupt and join a ui
thread before it becomes interruptible by blockign on a queue. To
workaround this, we can add the JoinThread class which adds an
extension method Thread.joinFor that takes a FiniteDuration parameter.
This variant of join will repeatedly interrupt and attempt to join the
thread for up to 10 milliseconds before retrying until the limit is
reached. If the limit is reached, we print a noisy error to the console.
I'm not 100% sure if we are leaking threads in the latest sbt version
but this gives me more piece of mind that either we are always
successfully joining the threads or we will be alerted if the joining
fails.
Moving forward, it would be great for sbt to use the latest code to run
the scripted tests. This could help detect regressions that aren't
noticed by manual dogfooding. We can do this by first publishing
1.4.0-SNAPSHOT binaries before running tests. I didn't want to do this
for all of the builds because it does make each build that publishes
binaries take about a minute longer. The last build in the matrix is
much faster than the other builds though so I made just that build use
the snapshot version. Since that build almost always finishes first,
this should have little effect on the actual time to run ci even though
the cpu time will increase a bit.
The CI output logs for the sbt build are truncated when using sbt
1.4.0-M2 because the virtual tty provided by the build agent doesn't
seem to work well with sbt's virtual io.
The travis tty does not work with virtual io. We should disable virtual
io by default when sbt detects that it's being run in CI but until we
release 1.4.0-M3 or 1.4.0-RC1, we need this flag to fix the travis
output.
Although log manager is in the internal package, akka uses it and it
seems worth preserving binary compatibility in their build, at least for
sbt 1.4.0-M2. Once the community build is passing, we can consider
reverting this.
```
[info] welcome to sbt 1.4.0-SNAPSHOT (AdoptOpenJDK Java 1.8.0_232)
[info] loading settings for project global-plugins from ...
[info] loading global plugins from ...
[info] loading project definition from /private/tmp/hello/project
[info] loading settings for project root from build.sbt ...
[info] set current project to hello (in build file:/private/tmp/hello/)
[info]
[info] Here are some highlights of this release:
[info] - Build server protocol (BSP) support
[info] - sbtn: a native thin client for sbt
[info] - VirtualFile + RemoteCache: caches build artifacts across different machines
[info] - Incremental build pipelining. Try it using `ThisBuild / usePipelining := true`.
[info] See http://eed3si9n.com/sbt-1.4.0-beta for full release notes.
[info] Hide the banner for this release by running `skipBanner`.
[info] sbt server started at local:///Users/eed3si9n/.sbt/1.0/server/478e6db75688771ddcf1/soc
```
While running ~scripted that multiple instance of the console terminal
were instantiated which caused problems with reading input. It turned
out that RunFromSourceMain was running in the same jvm process as sbt
and creating a new console terminal in a different classloader. This
both messed up the io of scripted tests when scriptedBufferLog was set
to false but it also made it so that I couldn't exit ~ with <enter>. To
workaround this, I deferred initializaiton of the console terminal to
Terminal.withStreams which is guarded by the sbt.io.virtual system
property.
In dogfooding sbt, I found that the WriteableInputStream used by the
console terminal initialized before it was needed. This would lead to
multiple instances of the WriteableInputStream being created, which
could lead to zombie threads reading from stdin. I'm not 100% sure what
the classloading scenario was that caused this to be a problem but in a
few days of using sbt after these changes, I haven't seem zombie
threads.
When exiting the thin client, an interrupted exception stack trace ends
up being printed because NonFatal doesn't include interrupted
exceptions.
Fixes https://github.com/sbt/sbt/issues/5759
Frequently ctrl+c does not work to cancel the running tasks. This seems
to be because the signal handler is bound to a specific instance of
evaluate task but there may be multiple instances of evaluate task
running at any given time. Shutting down just one of the running engines
does not ensure that task evaluation stops. To work around this, we can
globally store all of the completion services in a weak hash map and
cancel all of them whenever a signal is received. Closing the service,
which happens at the end of task evaluation will remove the service from
the map so hopefully this shouldn't introduce a memory leak.
While dogfooding the latest sbt, I noticed that sometimes the watch
input threads leak. I suspect this happens when a build is immediately
triggered by a file that was modified during compilation. Though I
didn't fully verify this, it's likely that we interrupted the input
reading thread before it actually started reading. When it started
reading after the interrupt, it would block until the user entered
another input character. The result was that the zombie thread would
effectively steal the next character from the input stream which
manifested as the first character being ignored when the user tried to
enter a watch input option. If more than one thread leaked, then it may
take a number of keystrokes before the user regained control.
To fix this, we can ensure that all watch related threads are joined
before we exit watch. To avoid completely blocking the ui, we only try
to join the threads for a second and print an error if the join fails.
This shouldn't be the case so if users see this error, then we need to
fix the bug.
In 0d2b00c7e9, I introduced a setting for
the virtual file defines class cache to avoid ooms coming from zinc
stamping the project jar files. I introduced that cache at the compile
level though rather than global level and crashes were still occurring
in the sbt build. It was very easy to induce a crash on my computer by
running compile a few times, reload and then compile again. After making
the cache global, the crashes went away.