-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
[wasm][aot] System.Text.RegularExpressions.Unit.Tests
failing due to Maximum call stack size exceeded
#66118
Comments
Tagging subscribers to 'arch-wasm': @lewing Issue DetailsHitting on rolling builds, and PRs. This is when building the tests with AOT, and happens on linux, and windows.
|
This seems to be only relevant commit compared the previous build that passed.
cc @stephentoub |
The purpose of TryEnsureSufficientExecutionStack is that code should be able to call it to know when it's too deep on the stack to do what it's about to do, and Regex uses that API to determine whether it can do certain processing. Seems like a mono bug if calling that API is producing some kind of exception about being too deep. The cited PR also didn't add any code that would trigger this, but it did move some tests around. Was the regex test suite previously being suppressed somewhere in this configuration? If so, its new unit tests project might also need to be suppressed in the same place. But it also seems like there's a bug here in mono that might have been previously hidden because of such suppression. |
SufficientExecutionStack probably has some problems on wasm. Does this happen on linux+wasm as well ? |
Yep, linux and windows. |
|
So it looks like that on wasm, TryEnsureSufficientExecutionStack cannot really be implemented since the real execution stack is hidden from the program. We can only check that we don't run out of the C stack which is in linear memory. |
Decreasing the depth in MinMaxLengthIsCorrect_HugeDepth to 5000 works around the problem. The recursion code should have some kind of hardcoded limit imho, |
It's using TryEnsureSufficientExecutionStack to avoid needing a hardcoded limit. This particular test is a stress test validating that behavior is functional. |
(Multiple places use TryEnsureSufficientExecutionStack for this same purpose, e.g. |
This is especially tricky for wasm given that different wasm runtimes have different limits and at times use wildly different amounts of execution stack for the same code. For AOT we may need to make a configurable limit based on testing. |
A configurable limit in TryEnsureSufficientExecutionStack, or a configurable limit everywhere that uses TryEnsureSufficientExecutionStack? I don't think the latter is reasonable in general (even if we were to do so everywhere we use it, we can't expect that to be true for all 3rd-party usage), but if there's really no way to correctly implement TryEnsureSufficientExecutionStack on wasm, imbuing it there with a conservative limit in TryEnsureSufficientExecutionStack seems like an ok fallback. |
A limit in TryEnsureSufficientExecutionStack, agreed about the latter. @radekdoulik can you take a look at this. |
removing 'blocking-clean-ci' as it's not, as zero regex tests are now running on WASM, pending a fix for TryEnsureSufficientExecutionStack. |
Hitting on rolling builds, and PRs. This is when building the tests with AOT, and happens on linux, and windows.
Build, and
log:
cc @radekdoulik @vargaz
The text was updated successfully, but these errors were encountered: