Bug 281662 – Transferring buffers to a closed MessageChannel causes memory leaks in Safari Networking

• Status: RESOLVED
• Resolution: FIXED
• Component: DOM

[Ivan Čurić]

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

[Radar WebKit Bug Importer]

<rdar://problem/138550781>

[Ivan Čurić]

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);

```

[Chris Dumez]

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.

[Chris Dumez]

(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.

[Ivan Čurić]

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.

[Brady Eidson]

Pull request: https://github.com/WebKit/WebKit/pull/55599

[EWS]

Committed 304642@main (ae1111af5882): <https://commits.webkit.org/304642@main>

Reviewed commits have been landed. Closing PR #55599 and removing active labels.