Using TruffleLogger outside of engine leads to crashes #8147
Comments
|
This is weird - I'm no longer to reproduce this one. And I know I used to be able to. |
|
So it looks like my change in #7985 has accidentally fixed it. |
|
Hubert Plociniczak reports a new STANDUP for yesterday (2023-10-24): Progress: Continued working on translating IR to Java (PR ready). Filed a ticket for forgotten logging problem (so far unable to reproduce using the old setup). It should be finished by 2023-10-26. Next Day: Next day I will be working on the #8147 task. Address feedback on IR translation pick up next item on the list. |
|
I am able to reproduce the problem even on recent bits: Enough to set with that I get: I am at 5e468f0 |
|
Hubert Plociniczak reports a new STANDUP for yesterday (2023-10-25): Progress: Addressing feedback to IR translation. Found out a potential race-condition leading to random CI failures (#8151). It should be finished by 2023-10-26. Next Day: Next day I will be working on the #8147 task. Address race-condition and switch to Truffle logger. |
|
Hubert Plociniczak reports a new STANDUP for yesterday (2023-10-26): Progress: Fixed a race-condition in CI (#8151). Worked on a Truffle logger-related task about inability to use custom logs (PR created). Tinkering with the solution for logger crash. It should be finished by 2023-10-26. Next Day: Next day I will be working on the #8147 task. Continue working on the task (delayed by other ones that happened in between). |
|
This is really odd. So #8169 provides somewhat a workaround for a case when we test the individual test. But when we run the full suite (e.g. |
|
Hubert Plociniczak reports a new 🔴 DELAY for the provided date (2023-10-27): Summary: There is 4 days delay in implementation of the Using TruffleLogger outside of engine leads to crashes (#8147) task. Delay Cause: Worked on other tickets inbetween. |
|
Hubert Plociniczak reports a new STANDUP for the provided date (2023-10-27): Progress: Kept tinkering with the (sometimes) failling example. Turns out the likely culprit is the kind of logger that gets created - we use TruffleLogger bound to the context rather than to the engine. That's bound to ocassionally fail with threadpools. It should be finished by 2023-10-30. Next Day: Next day I will be working on the #8147 task. Make sure that the hypothesis is correct, address PR comments |
Using a `TruffleLogger` in `SerializationManager` that is bound to the engine rather than the context prevents reaching an illegal state when using thread pools.
Also cleaned up some tests for consistency.
To verify the fix
```diff
--- a/engine/runtime/src/main/scala/org/enso/compiler/SerializationManager.scala
+++ b/engine/runtime/src/main/scala/org/enso/compiler/SerializationManager.scala
@@ -31,7 +31,7 @@ final class SerializationManager(compiler: Compiler) {
import SerializationManager._
/** The debug logging level. */
- private val debugLogLevel = Level.FINE
+ private val debugLogLevel = Level.INFO
```
and run
`sbt:enso> runtime/test`
Closes #8147.
github-project-automation
bot
moved this from 🔧 Implementation
to 🟢 Accepted
in Issues Board
|
Hubert Plociniczak reports a new STANDUP for the provided date (2023-10-30): Progress: Updated PR with a proper solution. Addressing comments. Investigating random apply edit failures. Planning next tasks. It should be finished by 2023-10-30. Next Day: Next day I will be working on the #8147 task. Address remaining comments for a related #8162. Continue with failures |
As pointed out in #8014 (comment):
and one gets:
Also noted similar problems when logging things in serializer. Can be simulated when problems occur in verbose mode.
The text was updated successfully, but these errors were encountered: