281662 2024-10-17 04:10:14 -0700 Transferring buffers to a closed MessageChannel causes memory leaks in Safari Networking 2025-12-17 19:51:43 -0800 1 1 1 Unclassified WebKit DOM Safari 18 Mac (Apple Silicon) macOS 26 RESOLVED FIXED InRadar P1 Critical --- 1 ivan.curic beidson ap bfulgham cdumez rreno slewis webkit-bug-importer ysuzuki oldest_to_newest 2068724 0 ivan.curic 2024-10-17 04:10:14 -0700 const { port1, port2 } = new MessageChannel(); port2.close(); port1.postMessage(e.data, [e.data.imageData.data.buffer]); This approach can be used to alleviate memory pressure in V8 as it forces GC. When used in Safari, this memory never gets GC'd, and the leak happens in the "Safari Networking" process for some reason, and can't be reclaimed until you restart Safari. You can't find this leak in the Web Inspector. Repro: Enable the option "Toss transferable to empty MessageChannel" and observe memory usage in Activity Monitor https://imagedata-worker-leak.netlify.app/ https://github.com/ivancuric/memory-leak-repro 2070327 1 webkit-bug-importer 2024-10-24 04:11:14 -0700 <rdar://problem/138550781> 2164135 2 ivan.curic 2025-12-08 08:58:37 -0800 Why isn't this assigned to anyone yet? I can literally crash anyone's device running Safari in seconds with the following snippet: ``` const { port1, port2 } = new MessageChannel(); port2.close(); setInterval(() => { const bufferBomb = new ArrayBuffer(1e8); // 100 MB const bomb = new Uint8Array(bufferBomb); port1.postMessage(bomb, [bomb.buffer]); }, 0); ``` 2164292 3 cdumez 2025-12-08 17:38:36 -0800 Pretty sure you can already do that by just allocating a lot of memory without returning to the runloop no? The JS running out of memory and causing the WebContent to crash is not uncommon. This is a bug for sure but saying you can crash anyone tab when you control the JS on the page does not make it higher priority or a security bug I think. Note that the bug is assigned to someone in radar but they are likely focusing on higher priority bugs at the moment. 2164363 4 cdumez 2025-12-09 00:48:11 -0800 (In reply to Chris Dumez from comment #3) > Pretty sure you can already do that by just allocating a lot of memory > without returning to the runloop no? The JS running out of memory and > causing the WebContent to crash is not uncommon. This is a bug for sure but > saying you can crash anyone tab when you control the JS on the page does not > make it higher priority or a security bug I think. > > Note that the bug is assigned to someone in radar but they are likely > focusing on higher priority bugs at the moment. Oh, the leak happens in the networking process! I had missed this part of the report, sorry. I wrongly assumed it was leaking in & crashing the WebContent process. This does make it higher priority indeed. I will see if we can this prioritized. 2164387 5 ivan.curic 2025-12-09 02:24:23 -0800 Thanks! Yeah, it leaks into the networking process, and IIRC it happens on iOS as well. It is also cumulative as long as the Safari process is open and persists across sleep/wake cycles. Before MacOS 26 I could get an OS-level OOM alert once it grew to >30GB of, I guess, compressed memory and the OS was still responsive enough to terminate Safari. However on 26.1 it just locks up and requires a power-button hard reset. 2166783 6 beidson 2025-12-17 17:23:38 -0800 Pull request: https://github.com/WebKit/WebKit/pull/55599 2166818 7 ews-feeder 2025-12-17 19:51:40 -0800 Committed 304642@main (ae1111af5882): <https://commits.webkit.org/304642@main> Reviewed commits have been landed. Closing PR #55599 and removing active labels.