Bug 284752 – [WebAssembly] iOS 18.2 RangeError: Maximum call stack size exceeded.

• Status: NEW
• Component: WebAssembly

Sites that used WebAssembly that used to work in previous iOS versions are now crashing with RangeError: Maximum call stack size exceeded. Has the stack depth limit become smaller?

https://bugs.webkit.org/show_bug.cgi?id=201028 Seems like a similar thing has happened before

[s-coding]

Im experiencing the same results. You can see for yourself at emulatorjs.org. Scroll down to the Flappy Bird demo and try to run it. 

[Error] RangeError: Maximum call stack size exceeded.
	quit_ (530d7e60-0f0e-41a7-af66-3fffecd34edc:8:307)
	handleException (530d7e60-0f0e-41a7-af66-3fffecd34edc:8:91699)
	callUserCallback (530d7e60-0f0e-41a7-af66-3fffecd34edc:8:92208)
	runIter (530d7e60-0f0e-41a7-af66-3fffecd34edc:8:93525)
	Browser_mainLoop_runner (530d7e60-0f0e-41a7-af66-3fffecd34edc:8:91284)

This worked before updating to iOS 18.2

[Alexey Proskuryakov]

Thank you for the report! Could you please provide specific steps to reproduce, and if possible, which exact versions of iOS did work?

[Radar WebKit Bug Importer]

<rdar://problem/141638512>

[s-coding]

(In reply to Alexey Proskuryakov from comment #2)
> Thank you for the report! Could you please provide specific steps to
> reproduce, and if possible, which exact versions of iOS did work?

When you are on emulatorjs.org, scroll down to the Flappy Bird demo and click "Start Game" The game will load, but will lock up almost immediately and the console output displays the "[Error] RangeError: Maximum call stack size exceeded" error. 
I was on 17.7.1 previously.

(In reply to s-coding from comment #4)
> (In reply to Alexey Proskuryakov from comment #2)
> > Thank you for the report! Could you please provide specific steps to
> > reproduce, and if possible, which exact versions of iOS did work?
> 
> When you are on emulatorjs.org, scroll down to the Flappy Bird demo and
> click "Start Game" The game will load, but will lock up almost immediately
> and the console output displays the "[Error] RangeError: Maximum call stack
> size exceeded" error. 
> I was on 17.7.1 previously.

I performed this test using the Xcode iOS simulator configured for iPhone 13 and 16, running both 18.1 and 18.2, and the Flappy Bird demo works correctly on both. While on my iPhone 13 Pro running iOS 18.2 the Flappy Bird demo crashes.

Not sure if it's a quirk of the simulator allowing it to work or not.

Yes I've haven't been able to reproduce it in the simulator. Seems to be related to inlining or loop unrolling, I can't seem to create a minimal reproduction. My code runs fine when compiled with emscripten with optimisation OO or O1 but not O2 O3 Os OZ

Code ran fine in all previous versions of iOS but crashes in 18.2 so would be a regression?

OP, are you using Asyncify? I'm investigating a very similar problem, blowing the stack on Safari 18.2 with the same Emscripten optimization flags as you. I'm building with Asyncify.

Hi apple-rth, yes we are using Asyncify. we were able to solve the problem by manually specifying which functions to instrument with ASYNCIFY_ADD. Otherwise it seemed like almost everything was being instrumented. Doing this fixed it for us.

Hi apple-rth, yes we are using Asyncify. we were able to solve the problem by manually specifying which functions to instrument with ASYNCIFY_ADD. Otherwise it seemed like almost everything was being instrumented. Doing this fixed it for us.

Okay, thanks! We see this on desktop Safari 18.2, and I was wondering why it wasn't being reported by more people. If it is primarily triggered by Asyncify-ed WebAssembly then that would be a reasonable explanation.

Here's another test page that may be simpler: https://rhashimoto.github.io/browser-test-cases/safari-stackoverflow/

Source: https://github.com/rhashimoto/browser-test-cases/tree/master/safari-stackoverflow

This page breaks desktop Safari 18.2. I know it works on Safari Technology Preview 212, but I'm hoping this will help developers confirm the underlying bug is actually fixed and not just masked by other changes.

We're also experiencing this regression. This regression makes our site completely unusable in Safari/Webkit completely unusable, forcing them to use Chromium instead. If Webkit is supporting WASM as a first-class citizen, then this is a serious regression.

Could you please consider bumping the priority on this to P1? I believe both of these conditions are true (thanks to [e-mail] 's nice reproduction).
- Any reproducible crash or hang.
- Any regression from a previous publicly released version of WebKit.

Thank you for your work!

[Mark Lam]

Please test on the latest Safari Technology Preview and let us know if the issue still reproduces.  Thanks.

@Mark Greatly appreciate the reply!

This does indeed seem to be fixed in the Safari Technology Preview 212. Thanks! However, there are two open concerns here:

1. Could you please confirm that this was fixed intentionally in 212? I see no mention of this in the [release notes](https://developer.apple.com/documentation/safari-technology-preview-release-notes/stp-release-212), so we want to make sure this was an intentional change.
2. Do you know approximately when 212 will be shipped to the live Safari channel? 212 was released on 01/23, but 18.3 was released on 01/27 without it included. Given that Safari has no scheduled release cadence, we're not sure what to tell our users here. (Recent updates seem to be ~every month or so, which is great! But older updates have gaps of many months between them).

Ideally someone should determine what commit caused this regression and what commit fixed (or masked) it, to see if that indeed makes sense. At minimum, testing on Asyncify-ed code needs to be in place to ensure that this failure isn't repeated.

(In reply to martin from comment #14)
> @Mark Greatly appreciate the reply!
> 
> This does indeed seem to be fixed in the Safari Technology Preview 212.
> Thanks! However, there are two open concerns here:
> 
> 1. Could you please confirm that this was fixed intentionally in 212? I see
> no mention of this in the [release
> notes](https://developer.apple.com/documentation/safari-technology-preview-
> release-notes/stp-release-212), so we want to make sure this was an
> intentional change.
> 2. Do you know approximately when 212 will be shipped to the live Safari
> channel? 212 was released on 01/23, but 18.3 was released on 01/27 without
> it included. Given that Safari has no scheduled release cadence, we're not
> sure what to tell our users here. (Recent updates seem to be ~every month or
> so, which is great! But older updates have gaps of many months between them).

18.3.1 doesn’t have the fix either :(