Bug 261685 – WK WebView Crash when loading / unloading images from VRAM while switching WebGL scene

• Status: NEW
• Component: WebGL

[Paul Rhomberg]

Created attachment 467738 [details]
Xcode project. Tested on Iphone 11 Pro

When loading or unloading images into video memory on iPhone inside of a WebView the application sometimes crashes. This happens more often when switching WebGL scenes or stressing the CPU. 
This does not seem to be related to the amount of vram being used, as it also occurs when unloading images from vram as well. 

I have attached the Xcode file. To test this application, launch the App on an actual device (it doesn't occur in the simulator, tested on iPhone 11 Pro) and click the "Switch" button around 5 times and always wait for the short loading screen + an additional second in between clicking the button. After that procedure, relaunch the App if it hasn't crashed and try again. This seems to work pretty well on my iPhone, I have a crash rate of around 20%. I have uploaded a video of how this could look here: https://drive.google.com/file/d/1rQlc8EQe4N_sDAcBen63S7CcT031AbX8/view?usp=drivesdk

This WebView application was made using the Construct 3 game engine. The developer claims that this bug is not related to the engine but rather WebKit. I have tested this exact app on various android devices, including ones that are far less powerful than the 11 pro and have not experienced crashes, even with devices that have 2GB of RAM. 

This is the crash log: 
2023-09-18 19:13:39.751673+0200 ios Crash example[13778:884444] [Process] 0x114004110 - [PID=13782] WebProcessProxy::didClose: (web process 0 crash)
2023-09-18 19:13:39.752061+0200 ios Crash example[13778:884444] [Process] 0x114004110 - [PID=13782] WebProcessProxy::processDidTerminateOrFailedToLaunch: reason=Crash
2023-09-18 19:13:39.753803+0200 ios Crash example[13778:884444] [ProcessSuspension] 0x11301c1e0 - ProcessAssertion: Failed to acquire RBS Background assertion 'XPCConnectionTerminationWatchdog' for process because PID 0 is invalid
2023-09-18 19:13:39.754144+0200 ios Crash example[13778:885053] [ProcessSuspension] 0x11301c1e0 - ProcessAssertion::acquireSync Failed to acquire RBS assertion 'XPCConnectionTerminationWatchdog' for process with PID=0, error: (null)
2023-09-18 19:13:39.769098+0200 ios Crash example[13778:884444] [Process] 0x105841a18 - [pageProxyID=14, webPageID=15, PID=13782] WebPageProxy::processDidTerminate: (pid 13782), reason=Crash
2023-09-18 19:13:39.799732+0200 ios Crash example[13778:884444] [Loading] 0x105841a18 - [pageProxyID=14, webPageID=15, PID=13782] WebPageProxy::dispatchProcessDidTerminate: reason=Crash
2023-09-18 19:13:39.869425+0200 ios Crash example[13778:884444] [Process] 0x1130807a0 - GPUProcessProxy::gpuProcessExited: reason=IdleExit
2023-09-18 19:13:39.869567+0200 ios Crash

[Paul Rhomberg]

20% was a bit optimistic. I just tested it again and now I had to relaunch the app around 15 times until it crashed again. It is very random, sometimes it happens often, other times only rarely.

[Shay Zhang]

I got this problem too while I'm trying to render a webpage with Three.js with a couple of models size aruond 1MiB. The error logs are identical, so I will not attach my log. Hopes somebody can take a look of this issue. It crashes at a rate  around 90% in my case on an iPhone 14 Pro.

[Radar WebKit Bug Importer]

<rdar://problem/116004636>

[Paul Rhomberg]

Did more testing with this using less images that fill up roughly 300MB of video memory. Crashes have become more rare but are still happening. Right before crashes I am seeing low memory warnings inside of Xcode even though the reported ram usage from Xcode is even lower than what Construct‘s Debugger is telling me. This seems a bit inconsistent / weird to me as I can normally fill up the iPhones‘ ram to roughly 1GB without crashes, yet I sometimes get low memory warnings having all applications closed and the iPhone reportedly using very little ram. Crashes happen in a matter of milliseconds after the low memory warning, I assume there must be some kind of memory leak involved.

[Alexander Sterk]

Had to make an account to say this is happening to me too.

I am making a game using Phaser and Capacitor. And I'm experiencing the same problem as you.

Occasionally during the preload phase, where textures are loaded/created, the webview will crash and restart. The App itself stays open and remains usable once the webview restarts.

I've put a lot of work into reducing the amount of textures and (un)load operations, and it seemed to 'fix' it. But I fear this is a band-aid, and not a fix of the underlying problem.

Even so, the amount of textures, and their sizes, were pretty small to begin with. And like mentioned above, the memory usage according to XCode is very low (roughly 20MB), and yet it appears to run out of VRAM. I'm very new to Xcode, so maybe this is on me, but I can't seem to find the VRAM usage anywhere. I do see a bit of a spike in the "Other processes" memory, so it could be in there.

The device I'm testing on is the iPad Pro 9.7 (1st gen, 2016), running the lastest iOS 16 version (idk from the top of my head, sorry). However the app also happens on my iPhone 12 running the latest iOS 17.
The app is built with a target of iOS 15. Have not tested if its related to that, but I would need it to work on that version at least. So even if that were a fix, it would not be usable for me.

Just my two cents...

[Kimmo Kinnunen]

Paul Rhomberg:
> When loading or unloading images into video memory on iPhone inside of a WebView the application sometimes crashes. This happens more often when switching WebGL scenes or stressing the CPU. 

Thank you for the report.
If you have a development version of the game that runs in a browser without the iOS app, attaching that would help a lot.

Shay Zhang:
> I got this problem too while I'm trying to render a webpage with Three.js with a couple of models size aruond 1MiB. 

Thank you for the report. If you are able to spend time on this, please file another bug report and attach your test case. If you are able to simplify your test case to minimal set of operations that fail, this would be helpful.

Alexander Sterk:
> Even so, the amount of textures, and their sizes, were pretty small to begin with. And like mentioned above, the memory usage according to XCode is very low (roughly 20MB), and yet it appears to run out of VRAM. I'm very new to Xcode, so maybe this is on me, but I can't seem to find the VRAM usage anywhere.

The memory would be attributed to process named com.apple.WebKit.WebContent and com.apple.WebKit.GPU instead of your app.

If you are able to, please file a new bug and provide a test case for the problem. The simpler the test case the better. If the test case works in a browser without the native app shell, that's even more helpful.

[Paul Rhomberg]

Hi Kimmo,
I've hosted an html build of the test game here:
https://bug261685-test.netlify.app/

However, I did some testing with this, and its behavior is a bit different.
Also, keep in mind that when you load this website, the engine loading is stuck at 0% for around 2 minutes, but only for the initial load. I assume this is because it's preparing for loading the textures. 

So, when the actual test application has started, it will freeze early when loading when it's the first time loading it up (I'm talking about the second loading screen, not the first one with the grey letters). If you then reload the page, it will freeze later on while loading (for me it is 82.5, in percent). However, I could not get it past this first "test". 

In comparison, the mobile app usually finishes the test and you have to press the button to switch layouts and start loading again a few times to get it to crash or even restart the app a few times. Here with the website, I could not get it to not freeze. That's also a difference - the website freezes, the app restarts the webview. But I assume this is part of how webview's in xcode work. 
I'm trying this out on the 11 Pro and I can get it quite far (82.5%) so I assume you might get past it on devices with more ram, unless there is a limit in Safari.