Closed hubertp closed 1 month ago
Possible fix to give unnamed threads some name doesn't help as this test isn't leaking the threads:
$ git diff
diff --git engine/runtime-integration-tests/src/test/scala/org/enso/interpreter/test/semantic/RuntimeManagementTest.scala engine/runtime-integration-tests/src/test/scala/org/enso/interpreter/test/semantic/RuntimeManagementTest.scala
index 876b42ab20..7f3b018f3a 100644
--- engine/runtime-integration-tests/src/test/scala/org/enso/interpreter/test/semantic/RuntimeManagementTest.scala
+++ engine/runtime-integration-tests/src/test/scala/org/enso/interpreter/test/semantic/RuntimeManagementTest.scala
@@ -47,7 +47,7 @@ class RuntimeManagementTest extends InterpreterTest {
}
def runTest(n: Int = 5): Unit = {
- val threads = 0.until(n).map(_ => new Thread(runnable))
+ val threads = 0.until(n).map(_ => new Thread(runnable, "RuntimeManagementTest-Thread"))
threads.foreach(_.start())
var reportedCount = 0
while (reportedCount < n) {
that names one of the testing threads.
Seems like every time RuntimeManagementTest is run, we keep two threads up and running:
What do you mean. "Every time" it is run? I can:
sbt:runtime-integration-tests> testOnly *RuntimeManagementTest
however that runs the test only once. How do I reproduce "every time"?
Taking heap dump shows the Thread-144 hanging there after RuntimeManagementTest
gets executed in a sequence of tests started by
sbt:runtime-integration-tests> test
is a LanguageSystemThread
:
The Thread-143 is also LanguageSystemThread
. Nobody has references to them. They point to the same instance of PolyglotImpl
via the polyglot
field. And to two different instances of PolyglotContextImpl
via the polyglotContext
field.
There are four tests in RuntimeManagementTest
and only the last three are leaving the threads behind. The first one creates new suspicious threads:
[info] RuntimeManagementTest:
[info] Enso Code Execution
[info] when Context is Cached
SLF4J: Attempting to load provider "org.enso.logger.TestLogProvider" specified via "slf4j.provider" system property
[info] - should Interrupt threads through Thread#interrupt() (1 second, 812 milliseconds)
[info] - should Automatically free managed resources !!! IGNORED !!!
[info] - should Automatically free managed resources amongst manual closure of other managed resources !!! IGNORED !!!
[info] - should Automatically free managed resources amongst manual takeover of other managed resources !!! IGNORED !!!
[info] Enso Code Execution
[info] when Context is Uncached
[info] - should Interrupt threads through Thread#interrupt() (326 milliseconds)
[info] - should Automatically free managed resources !!! IGNORED !!!
[info] - should Automatically free managed resources amongst manual closure of other managed resources !!! IGNORED !!!
[info] - should Automatically free managed resources amongst manual takeover of other managed resources !!! IGNORED !!!
Found 0 suspicious threads
[info] Test run org.enso.interpreter.test.instrument.RuntimeManagementCleanupTest finished: 0 failed, 0 ignored, 1 total, 1.057s
Culprit: RuntimeManagementTest
doesn't close the EnsoContext
!
Jaroslav Tulach reports a new STANDUP for yesterday (2024-08-26):
Progress: - note about run a node in different context: https://github.com/enso-org/enso/issues/10719#issuecomment-2309747331
Elevate your Oracle experience with Premier Support for risk mitigation, cost reduction, and comprehensive system protection. Get expert 24/7 service and security.
Culprit:
RuntimeManagementTest
doesn't close theEnsoContext
!
At the end
fixes the problem by finishing the threads when they become idle.
Jaroslav Tulach reports a new STANDUP for yesterday (2024-08-27):
Progress: - minimizing moving parts: https://github.com/enso-org/enso/pull/10890/commits/3c28bc975e50f075a726d47e2cc8dbfbd7f2ef94
FramePointer
: https://github.com/enso-org/enso/issues/10843#issuecomment-2312922888Jaroslav Tulach reports a new STANDUP for yesterday (2024-08-28):
Progress: .
buildDescriptor
PR: https://github.com/enso-org/enso/pull/10906Supplier<TruffleObject>
attempt: https://github.com/enso-org/enso/commit/6ee9c8f80feb3caa8ec26b2d735451efd22c91cdGitHubPull Request Description Introduces new startup "Hello World" benchmark with many imports and a performance improvement by delaying loading classes in registerPolyglotSymbol. Checklist Pl...
DiscordDiscord is great for playing games and chilling with friends, or even building a worldwide community. Customize your own space to talk, play, and hang out.
As revealed in the investigation related to memory leaks.
Seems like every time
RuntimeManagementTest
is run, we keep two threads up and running:Not sure if this is caused by the bug in a test or in the implementation (finalizers) of ManagedResource.