runtime: System.Linq.Expressions.Tests.CompilerTests.CompileDeepTree_NoStackOverflowFast overflows stack with Checked CoreCLR build
CompilerTests.CompileDeepTree_NoStackOverflowFast overflows the stack with Checked (and presumably Debug) builds of CoreCLR. See comment.
This makes it problematic for us to use CoreFx tests to validate CoreCLR. Is it reasonable to reduce the complexity of the test so that it fits on the stack regardless of runtime build type? If not, can you recommend an attribute to tag this test so we can disable it in CoreCLR runs?
Repro (Windows, from dotnet/coreclr repo!)
build x64 checked skiptests
python tests\scripts\run-corefx-tests.py -build_type Checked
(There are likely simpler repro steps that can be distilled from the operation of run-corefx-tests.py, but those are left as an exercise for the reader.)
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Comments: 19 (19 by maintainers)
Commits related to this issue
- Increase stack size for CompileDeepTree_NoStackOverflowFast Should allow it to run with checked coreclr builds, but still test the stack-overflow guards without running for a long time. Fixes #17550 — committed to JonHanna/corefx by JonHanna 7 years ago
- Increase stack size for CompileDeepTree_NoStackOverflowFast Should allow it to run with checked coreclr builds, but still test the stack-overflow guards without running for a long time. Fixes #17550 — committed to JonHanna/corefx by JonHanna 7 years ago
- Increase stack size for CompileDeepTree_NoStackOverflowFast Should allow it to run with checked coreclr builds, but still test the stack-overflow guards without running for a long time. Fixes #17550 — committed to JonHanna/corefx by JonHanna 7 years ago
- Increase stack size for CompileDeepTree_NoStackOverflowFast Should allow it to run with checked coreclr builds, but still test the stack-overflow guards without running for a long time. Fixes #17550 — committed to JonHanna/corefx by JonHanna 7 years ago
I tried changing stack size here to 192k. The test now passes with a Checked runtime, and this line is hit multiple times during the test, which I think indicates the code is taking the intended path. If I increase the stack size to 256k, the “false” path is no longer taken, so that would be too much stack. This is all with a Checked runtime. I haven’t tried a Release runtime.
Changing the stack size seems like a more promising path than disabling the test to me.