NEW 281656
Web Inspector: Memory leak with high-bandwidth operations on web workers when inspector is open
https://bugs.webkit.org/show_bug.cgi?id=281656
Summary Web Inspector: Memory leak with high-bandwidth operations on web workers when...
Ivan Čurić
Reported 2024-10-17 01:00:00 PDT
Created attachment 472966 [details] Video showcasing the memory leak in Activity Monitor Opening the Web Inspector, even without any logging or inspection done, leads to a memory leak that only happens once - until the first page crash or stabilization. When it does crash, it either ends up being a completely crashed tab, or I get a message bar with "This web page was reloaded because it was using significant memory". The memory leak is not present in the "Safari Web Inspector process", but in the tab process itself. However, it's not visible in the Memory timeline in the inspector. Repro: https://imagedata-worker-leak.netlify.app https://github.com/ivancuric/memory-leak-repro
Attachments
Video showcasing the memory leak in Activity Monitor (14.93 MB, video/quicktime)
2024-10-17 01:00 PDT, Ivan Čurić
no flags
Radar WebKit Bug Importer
Comment 1 2024-10-24 01:00:17 PDT
Andrew Hodel
Comment 2 2024-11-03 08:11:22 PST
I confirm this bug. 1. Enable the Memory chart in Web Inspector -> Timelines 2. Reload the document until the memory chart begins to work (it doesn't work every time in Safari 18.1). If you keep a `Worker` thread running and make a request to it every second with `Worker.postMessage` expecting a response to each request that is created in the worker with `postMessage({id: 'aaaa', data: new ArrayBuffer(5000000)})` you can watch the `Memory` chat in Web Inspector -> Timelines grow until the tab is force reloaded.
Andrew Hodel
Comment 3 2024-11-07 06:52:47 PST
If you create a `Worker` that has a `postMessage` function that includes a transferred object and never use the `Worker` Safari never deallocates memory. There is no reason for it, there is a return statement in the `Promise` that sends a message the `Worker`. If that return statement was not there, it would be allocated but it is being allocated anyway and if it is specified as a transferred object (meaning in the 2nd argument's array with postMessage) it gets allocated and not used every time it would be called. This means that when you write the code to work with browsers that support Workers, if you use transferred objects Safari as described in the previous paragraph, Safari continues to have a memory leak.
Andrew Hodel
Comment 4 2024-11-07 07:02:54 PST
More information about Comment 3: Safari is obviously allocating for transferred objects in Worker code that is expected to run due to an invocation of `postMessage` in the main thread without regard to there being a return statement that is conditional of the Safari browser before the `postMessage` in the main thread.
Andrew Hodel
Comment 5 2024-11-07 19:15:06 PST
This is still a bug, but ignore comments 3 and 4. It's not about allocating for expected transferred objects from a Worker thread and excluding a return statement before in the code that starts the Worker routine. I re-enabled the transferred object for non Safari browsers that don't have the memory leak bug 281656 is explaining and with 110MB of 3D meshes created every 2000ms the memory fills at that rate. If I change only the interval timing from 2000ms to 100ms, meaning now add 110MB of 3D to a WebGL canvas every 100ms instead of 2000ms the memory is deallocated each 100ms loop. This is with 8 Worker threads, each using 70MB of memory while not executing anything on an iPad with 8GB of memory. **It seems that Safari is adding items to memory and not deallocating those when it should if there is a non constant modification rate, based on a 1 second measurement interval. That could be to base a measurement of too much memory usage, because at a 2000ms redraw interval it does reload the document within 30 minutes.** Regardless, it works if I set a 100ms redraw interval.
Andrew Hodel
Comment 6 2024-11-08 06:04:24 PST
This issue should have a different title. It works with transferred objects in Worker threads, still running with a 100ms redraw interval after 10 hours. If I change only the redraw interval to 2000ms it fails within 30 minutes.
Andrew Hodel
Comment 7 2024-11-08 14:00:43 PST
It works at redraw each 5s and 100ms but not 2s.
Andrew Hodel
Comment 8 2024-12-14 16:49:05 PST
This problem was caused by the THREE.js GLTFLoader that only causes a memory leak in Safari and works in Chrome. Proof - https://jsfiddle.net/n1vebmug/2/ Please close this bug report.
Note You need to log in before you can comment on or make changes to this bug.