-
-
Notifications
You must be signed in to change notification settings - Fork 410
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
Crash in a scheduler exhaustion example #2441
Comments
P.S. no rush, by the way. Reporting it, as Pony's stability might be endangered |
curiously, adding some calculation in the tight loop does makes the program run without a crash if (_counter % 1000000000) == 0 then
_env.out.print("ping")
end https://gist.github.com/d-led/a92c1e4aa51b87f587976995d397dbcb I'd expect that the existing tight loops would continue to create output, though |
with debug runtime but release build. looks like a gc bug. (lldb) run
(lldb) bt
|
The bug is triggered by Not sure why though. |
I don't have time to investigate further but... this happens in
given that will always be true, i'm interested to see what LLVM is producing in release mode as an optimization. This for example, has no segfaulting issues:
|
@d-led you should be able to keep working and get your desired effect with this:
|
@SeanTAllen thanks for your investigation! Will continue poking around + use your proposal |
Sylvan reports this does not segfault for him on Windows with LLVM 3.9.1 |
i was able to reproduce this on ubuntu linux with pony:
|
I changed It also works if work is done before the loop that can't be optimised away (for example, printing something to env.out). It appears that As to why LLVM is turning that "jmp to self" into ud2, I'm not sure. |
Many parts of the LLVM optimiser treat infinite loops with no side-effects as causing undefined behaviour, based on the C++ standard. The LLVM IR itself doesn't define infinite loops very well. This is a recurrent topic on the LLVM mailing list. See for example here and here. |
FYI, as of 0.37.0 this is still a problem with optimized builds. However, the error is a little different.
|
a side remark, the Go run-time has managed to implement tight loop pre-emption |
I am no longer able to reproduce this as of ponyc 0.46.0. |
This probably got fixed when we upgraded to LLVM 12, which allowed to have infinite loops at the IR level. |
can confirm. Nice. Although, the scheduler exhaustion is not that nice - it's a trade-off :) |
Hi,
I was writing an example of how monopolizing the scheduler threads with tight loops could lead to standstill. Expected behavior: some output, then full CPU load, but no output. However, the program seems to crash pretty soon (in release mode). The same program does not crash in debug mode:
on Windows:
ponyc && test.exe
→ crash, butponyc --debug && test.exe
→ no crashsame on OSX:
For a cross-check, 0.20 crashes too:
The text was updated successfully, but these errors were encountered: