Repository navigation
Stack overflow in Mono interpreter on some System.Threading.Tasks.Dataflow.Tests tests #38817
Description
Description
===========================================================================================================
~/work/AA0C09B2/w/A5730975/e ~/work/AA0C09B2/w/A5730975/e
Discovering: System.Threading.Tasks.Dataflow.Tests (method display = ClassAndMethod, method display options = None)
Discovered: System.Threading.Tasks.Dataflow.Tests (found 290 of 297 test cases)
Starting: System.Threading.Tasks.Dataflow.Tests (parallel test collections = on, max threads = 2)
Stack overflow: IP: 0x7fa1a0f1e061, fault addr: 0x7fa15effa010
Stacktrace:
~/work/AA0C09B2/w/A5730975/e
----- end Tue Jun 30 23:02:46 UTC 2020 ----- exit code 1 ----------------------------------------------------------
Supposedly this is a regression because stack limits were added to the interpreter, and some Dataflow tests use a LOT of stack.
Configuration
Interpreter on x64 Linux
Regression?
This broke some time between when interpreter tests stopped running in the interpreter (possibly in 9929c07) and now.
Filing an issue, mostly so I can ActiveIssue the tests & re-enable interpreter testing.
Activity
BrzVlad commentedon Jul 13, 2020
For reference, this is caused by #38085. After that change, we have fixed sized stack, and we no longer allocate stack fragments forever from the OS. I'm not comfortable increasing the stack size just because this test stress tests it. I think the async/task code has a limit on how much it should execute synchronously (in recursive fashion), if asked to. If that's the case, maybe this limit should be tweaked for interpreter.
lambdageek commentedon Sep 24, 2021
This also repros on MacCatalyst using the interpreter - see #52460
I think there maybe some issue with available stack detection in the async code - it seems like the code executes and we get SIGBUS errors or stack corruption. Although I couldn't get an informative stack trace