Bug 257371

Summary:	Revoking with URL.revokeObjectURL() does not adequately free memory
Product:	WebKit	Reporter:	Nathan <nathan>
Component:	WebCore JavaScript	Assignee:	Nobody <webkit-unassigned>
Status:	NEW ---
Severity:	Normal	CC:	ap, cdumez, lmcliste, mark.lam, pangle, webkit-bug-importer, youennf
Priority:	P2	Keywords:	InRadar
Version:	Safari 16
Hardware:	All
OS:	All

Description Nathan 2023-05-26 02:17:02 PDT

URL.revokeObjectURL() does not appear to free the associated memory. A window/tab will eventually crash from memory exhaustion after navigating through of an SPA that creates and revokes object URLs. 

We've created a demo which can reproduce the memory leak and cause a tab to crash in iOS Safari, and cause memory consumption to climb to great heights in macOS Safari:

https://github.com/shareup/blob-url-memory-leak-demo

The demo creates and revokes 100 object URLs each iteration, to emulate paginating through screens of images in an SPA. The demo consistently shows the memory increasing and the tab will crash after enough iterations on all the iOS devices we've tested. There are screenshots in linked README of the memory timeline during a couple demo test runs.

It is not required to display the images – and the demo does not render anything by default – just creating (and attempting to revoke) the object URLs will show memory forever increasing in the Timelines tab of the devtools and will eventually cause the tab to crash when memory consumption gets too high. 

We have not found a workaround for how to free the memory, so any long-lived tab for an SPA will eventually crash when enough object URLs have been created and allocated. Neither Chrome nor Firefox on macOS show a similar memory leak.

Comment 1 youenn fablet 2023-05-29 23:31:09 PDT

I tried it on my Mac book. I can reproduce memory increase on a recent Safari version when the web inspector is opened and when running the test.
When the web inspector gets closed, the memory quickly decreases back to normal.

@Nathan, can you reproduce the issue if Web Inspector is not opened?

Comment 2 Nathan 2023-06-08 07:45:44 PDT

@youenn OK, on macOS I've also seen Safari can usually handle the memory growth or maybe the memory growth is only happening with the devtools open. Usually, macOS Safari does not fully crash the tab if it's running on a good machine.

However, I just tested the demo page on an iPhone SE with Safari 15 and it did indeed crash after paginating through about 20 or so pages. I did not have the devtools connected / open. Testing on an iPhone 14 with Safari 16.5, it made it further along, but then eventually crashed for me as well. We also have seen these crashes "in the wild" when testing our app with people.

Do you see the memory growth + crash on iOS as well?

Comment 3 Radar WebKit Bug Importer 2023-06-08 07:45:57 PDT

<rdar://problem/110464755>

Comment 4 youenn fablet 2023-06-13 05:01:24 PDT

Using https://jsfiddle.net/o6pbz14d/2/ on macOS+WebInspector, I can see the memory growth, but I do not see it on my iOS device.
@Nathan, please let me know whether you can reproduce the crash in https://jsfiddle.net/o6pbz14d/2/.

The issue might be solved in WebKit trunk, we made a few changes in that area.

Comment 5 Nathan 2023-06-13 07:18:11 PDT

@youenn the jsfiddle you shared appears to only have 37 unsplash URLs in the array, so it's not actually creating 100 object URLs during each run. This made the test much easier for the browser to run, and I think doesn't demonstrate the issue as readily unless you run it with a much higher number of pages/batches.

I've created a jsfiddle here which has all unsplash images from my original demo and I've verified that it is actually creating 100 object URLs now during each run. Here is the URL to the forked jsfiddle I made: https://jsfiddle.net/myobie/x8z7kh9a/8/

(It's tough for jsfiddle to render the JS code with that many URLs... sorry.)

I ran it on macOS 13.4, iPhone 14 with iOS 16.5, and an iPhone 14 Pro with iOS 16.5.

macOS: made it through the test. The test appears to run smoother than it did before, but maybe that is just my perception. I don't have actual data to back that up.

iPhone 14: crashed the tab before it made it through the test.

iPhone 14 Pro: took a while, but it did make it through the entire test. 

You mentioned that there was some work done in trunk recently released to this. Are there any tests to verify that the memory is cleaned up when the URL is revoked?