-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sporadic test errors since upgrading to Native 0.5 #4647
Comments
Alright. What if we divide tests into two groups for Native build? |
@danicheg Unfortunately the problem is likely a bug with MUnit or Scala Native itself. MUnit was hastily upgraded to multithreading. |
I wonder – are there some other projects that suffer from the similar issue after upgrading to ScalaNative v5.x? |
It seems that when some tests fail, they do not fail because of any particular error – they just do not start:
I see these errors in one of the last runs, but I cannot find any clue on what caused those failures. Those are just failed 🤷 |
I'm not sure about how munit failed tests are reported, but when using JUnit in Scala Native project itself we got 2 categories:
Based on the log above I think it touches the later category of fatal errors. It means we might need to investigate on the munit - scala native boundary |
Here's another recent one. https://github.com/typelevel/cats/actions/runs/12486161618/job/34845910566#step:14:16127
|
Yes, I believe what is happening is that there are a number of test runners executing in parallel. Each runner is assigned some subset of the total test suites. It seems like if a test runner encounters a fatal error (eg segfault) in one of its suites, it dies, causing all other suites assigned to that runner and not yet completed to also be considered "errored". |
@armanbilge , I wonder can those SEGFAULT errors be somehow related to tests that check for stack safety issues? I mean, there are a plenty of tests in Cats that run quite memory-intense calculations just in order to make sure that there are no stack overflow errors. So I'm wondering – could such tests be actually the culprits? |
If those tests were failing, and they were stackoverflowing, then that could manifest as a segfault. But if the tests are using constant stack space (as they should) then it shouldn't be an issue. It's worth checking out :) |
That might be possible. Currently SN lacks proper handling for StackOverflowExceptions and OutOfMemoryError. The first one should be fixable by introducing canaries / signal handlers to recover from stack overflow. Similary we could try to handle OOM errors. |
Most recently https://github.com/typelevel/cats/actions/runs/10556403923/job/29242594012
But this has been haunting us since we upgraded.
The text was updated successfully, but these errors were encountered: