Bug 303203 – macOS/iPadOS 26 memory leak in com.apple.Webkit.GPU process when running simple WebGPU app

• Status: RESOLVED
• Resolution: FIXED
• Component: WebGPU

## Summary
After update to ipadOS 26 (Safari) our application started crashing, this was further narrowed down to `com.apple.Webkit.GPU` process being killed by the system due to running out of memory. 
Managed to repro using relatively simple web-gpu setup/calls. There were no issues on v18 across multiple devices.

## Environment
- **Device**: iPad A16 (also tested on newer iPads, iPhone 12 and Mac M3, they all behave same after update to 26)
- **Browser**: Safari
- **Cross-platform**: No issue in windows chrome / android chrome, also GPU usage doesn't show leak

 ## Reproduction Steps

On iPadOS26: (MacOS 26 behaves same way and may be easier to use for repro, however on mac getting process crash takes much longer - instruments confrm memory use increasing and not getting released though)

1) Run github web-gpu sample: https://orillusion.github.io/orillusion-webgpu-samples/#rotatingCube
2) Observe in xcode instruments com.apple.WebKit.GPU process Memory starts growing steadily (sometimes only after a minute or so). This does not stop and grow till system kills the process

* The speed of the leak can be improved by rendering with multiple commandEncoders
1) Clone repo https://github.com/handzlikchris/orillusion-webgpu-samples
2) run examples with `npm run dev`
3) Observe in xcode instruments com.apple.WebKit.GPU process Memory starts growing steadily (sometimes only after a minute or so). This does not stop and grow till system kills the process

Our app is more complex and mrmory leak is much more obvious and problematic although that simple repro scenario shows it well.

[Radar WebKit Bug Importer]

<rdar://problem/165488672>

[Mike Wyrzykowski]

This is easily reproducible

[Mike Wyrzykowski]

Memory usage appears to climb to around ~650MB and then stop, but this is unattributed usage leading to GPU process jetsam as noted

[Mike Wyrzykowski]

This might be addressed by https://bugs.webkit.org/show_bug.cgi?id=302711, attempting to confirm

[Mike Wyrzykowski]

302711 seems to help but is not necessarily related.

It appears something is not getting GC'ed but we expect it to. Going to look at live object counts

[Mike Wyrzykowski]

WebGPU object counts appear fine, on the rotating cube example:

------------------------------------------------------------
Queue: 2
BindGroup: 2
TextureView: 5
Adapter: 2
Device: 2
PresentationContext: 2
Buffer: 3
ComputePassEncoder: 2
CompositorIntegration: 2
RenderPipeline: 2
CommandEncoder: 2
CommandBuffer: 2
Texture: 5
BindGroupLayout: 2
PipelineLayout: 2
RenderPassEncoder: 2
------------------------------------------------------------

[Mike Wyrzykowski]

Diffing two memgraphs shows:

Object Allocation Bytes (from heap):
                                                                                                      Unit         Δ               #0        #1  
non-object in zone WebKit Using System Malloc                    KB    366511.6  293359.7  659871.3


an increase of ~316MB in non-object WebKit allocations

[Mike Wyrzykowski]

MallocStackLogging shows:

malloc in WebGPU::CommandEncoder::trackEncoder(WebGPU::CommandEncoder&, WTF::Vector<unsigned long l…  KB    657200.0  2624    659824

[Mike Wyrzykowski]

void CommandEncoder::trackEncoder(CommandEncoder& commandEncoder, Vector<uint64_t>& encoderContainer)

encoderContainer	WTF::Vector<unsigned long long> &	0x0000000bd68434e0
WTF::VectorBuffer<unsigned long long, 0, WTF::FastMalloc>	WTF::VectorBuffer<unsigned long long, 0>	
WTF::VectorBufferBase<unsigned long long, WTF::FastMalloc>	WTF::VectorBufferBase<unsigned long long, WTF::FastMalloc>	
m_buffer	unsigned long long *	0x446000000	0x0000000446000000
m_capacity	unsigned int	10236253
m_size	unsigned int	8609471

[Mike Wyrzykowski]

8 million tracked encoders

[Mike Wyrzykowski]

That seems to be the issue. Memory is stable removing that line

[Mike Wyrzykowski]

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

[Mike Wyrzykowski]

Memory usage seems stable now running rotating cube for over an hour

That's awesome, thanks for really quick investigation and fix. Really appreciate that. 

How does generally releases of those kind of bug fixes look like? 
We're trying to understand how hard we need to look into some mitigation on our end till fix lands, just rough timeframe would be great.

Also if mitigation is needed - can you provide any advice based on the fix where we can focus to reduce the rate-of-leak and therfore extend the time app runs till it's jetsam'd?

Already looking at reducing number of per-frame encoders where we can as we've seen that seemed to help and wondering if we can make any more progress by reducing use of other resources?

Currently we have:
------------------------------------------------------------
BindGroup: 203 created once
TextureView: recreated every frame, grow to around 500-1000 before they get collected and start growing from 1 again
Adapter: 1 created once
Device: 1 created once
Buffer: 274 created once (amountingto 800MB)
ComputePassEncoder: 80 per-frame (this is the main one we're looking into right now)
RenderPipeline: 45 created once
CommandEncoder: 6 per-frame
Texture: 39 (amounting to 250MB)
BindGroupLayout: 34 created once
PipelineLayout: 31 created once
RenderPassEncoder: 17 (per frame)
------------------------------------------------------------

Thanks again!

[Mike Wyrzykowski]

I can't comment on timelines but after the fix is merged into WebKit main, it usually appears first in Safari Technology Preview https://developer.apple.com/safari/resources/

I can comment on this bug when I notice the fix in Safari Technology Preview and once it appears in a beta of iOS and macOS

That'd be awesome, thanks again.

[EWS]

Committed 303984@main (f37648d61312): <https://commits.webkit.org/303984@main>

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