-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # 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: