-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
System.Linq.Expressions CompileDeepTree_NoStackOverflowFast fails with Stack Overflow #53309
Comments
@jakobbotsch want to take this one? |
The issue is that the native PGO data we are passing after d435388 causes MSVC to use more stack space in The importer already limits the depth of trees it can create: runtime/src/coreclr/jit/importer.cpp Lines 11234 to 11252 in 44f050a
We could decrease this limit, though that seems unnecessary. The original point of this test was to have a fast inner loop test corresponding to the slower outer loop one above it. However, in #21374 this new test was also moved to outer loop, so it does not seem like there is much point in having it anymore. |
The manually assigned 128 KiB stack here is bordering on the amount of stack space that release JIT needs to JIT functions with deep trees. Since the JIT already has a limit on the depth of trees it creates https://github.com/dotnet/runtime/blob/44f050acc0f7791d6cd7ac772945444912bcf299/src/coreclr/jit/importer.cpp#L11234-L11252 it seems unnecessary to pressimize the JIT further to allow this test to pass. Also, the test was originally added as a faster equivalent to the test above it that could run in inner loop (dotnet/corefx#14444), but it was subsequently moved to outer loop (dotnet/corefx#19563), so now it does not seem like there's much point in retaining it. Fix dotnet#53309
Recent runs that observed the failure: first, second. Test in question.
To diagnose the cause, I used the following snippet:
Release runtime + Release Jit were tested (since that's what the CI was using), with tiered compilation off.
git bisect
showed the following:- Commits before d435388 only needeed
X
of 65 to succeed.- Commits after and including d435388 needed
X
of 129 and above to succeed, matching the timing of the failures in CI (this test succeeded on 21st of May).This test has a history of failing on Debug Jits (indeed, an attribute pointing to just that) - see #21374. But now, apparently, it needs 129 KB of stack even in Release. I am not sure what is the proper fix for this.
cc @AndyAyersMS
The text was updated successfully, but these errors were encountered: