Bug 309251 – REGRESSION (iOS 26): Page jetsams every ~30s with IndexedDB atomic writes in Web Worker on a performance test

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: Website Storage

[Furkan Arabaci]

## Summary
Starting in iOS/iPadOS 26, pages using IndexedDB with atomic batch writes in a Web Worker experience automatic page refreshes approximately every 30 seconds. This is a regression - earlier iOS versions do not exhibit this behavior.

## Impact
- Only physical iOS devices (26+), for some reason simulators work fine.
- Reproducible 100% of the time
- No console errors or visible crash reports

## Steps to Reproduce
1. Open https://rhashimoto.github.io/wa-sqlite/demo/benchmarks/?config=asyncify,IDBBatchAtomicVFS;asyncify,IDBMirrorVFS;default,AccessHandlePoolVFS;default,OPFSCoopSyncVFS;asyncify,OPFSAdaptiveVFS;asyncify,OPFSPermutedVFS on physical iOS 26+ device
2. Click "Run benchmark"
3. Observe: Page automatically refreshes within ~30 seconds during or after execution

## Expected Behavior
Page should remain stable - Web Workers should never be able to trigger page reloads.

## Actual Behavior
Page refreshes approximately every 30 seconds when IndexedDB atomic batch writes occur in Worker context.

## Technical Context
- Other VFS types (not using atomic IndexedDB batches) work normally
- Issue reference: https://github.com/rhashimoto/wa-sqlite/issues/310

## Platforms Tested
✅ Works: Android, Windows, macOS, iOS 26 and earlier
❌ Fails: iOS 26+, iPadOS 26+

## Why This Matters
This appears to be a critical WebKit regression. Web Workers should never be able to initiate page reloads - this violates fundamental web platform security and stability guarantees.

## Regression Information
- First broken version: iOS 26
- Still broken: iOS 26.4 Beta

## Device Information
- [List specific devices tested, e.g., "iPhone 17 Pro, iOS 26.2.1"]
- [iPad Mini, iPadOS 26.4 Beta]

[Alexey Proskuryakov]

Thank you for the report! I can reproduce this on iPad mini (tried 5th and 6th generation, reproduced on both). Could not reproduce on iPhone 17 Pro.

Tried with 26.2 and 26.4 beta, so I didn't attempt to reproduce if this is a regression.

What I see is jetsams, i.e. running out of memory.

> Page should remain stable - Web Workers should never be able to trigger page reloads.

I don't think that this is entirely accurate, using too much memory is expected to cause a reload, and benchmarks are particularly prone to this. So this is not necessarily a bug at all.

However it is concerning if this worked before and doesn't now, it could mean that we are using more memory now, or perhaps inaccurate memory use limits.

[Radar WebKit Bug Importer]

<rdar://problem/171827600>

[Furkan Arabaci]

(In reply to Alexey Proskuryakov from comment #1)
> Thank you for the report! I can reproduce this on iPad mini (tried 5th and
> 6th generation, reproduced on both). Could not reproduce on iPhone 17 Pro.
> 
> Tried with 26.2 and 26.4 beta, so I didn't attempt to reproduce if this is a
> regression.
> 
> What I see is jetsams, i.e. running out of memory.
> 
> > Page should remain stable - Web Workers should never be able to trigger page reloads.
> 
> I don't think that this is entirely accurate, using too much memory is
> expected to cause a reload, and benchmarks are particularly prone to this.
> So this is not necessarily a bug at all.
> 
> However it is concerning if this worked before and doesn't now, it could
> mean that we are using more memory now, or perhaps inaccurate memory use
> limits.

Hello Alexey,
Thank you for taking your time with the report! That's odd, I was able to reproduce on iPhone 17 Pro. 

That likely solidifies this is a out of memory thing.

> and benchmarks are particularly prone to this. So this is not necessarily a bug at all.

According to what I experienced, this is valid on any PWA(or web page) which uses `idb-atomic-batch`, but I posted benchmark as an example because it's easier than to create a new site specifically for this 😅

Yes, it was working before, before iOS 26 but I am not sure which specific version it started to fail.

I have two pieces of information that might be relevant:

1. The reproduction page uses a WebAssembly build (of SQLite) with Emscripten Asyncify, which is known to require more resources than non-Asyncify builds.

2. A couple years ago, this bug

https://bugs.webkit.org/show_bug.cgi?id=284752

reported a similar problem: Asyncify builds exhausted a resource and caused a regression where previously working web pages crashed.

Note that bug was closed only because a new Safari version began working without any documented investigation (despite pleas to confirm that the underlying problem was actually fixed and not simply masked) and no obvious connection to any PR. I'm wondering if this new report might be related.

[Ben Nham]

> https://bugs.webkit.org/show_bug.cgi?id=284752
> reported a similar problem: Asyncify builds exhausted a resource and caused a regression where previously working web pages crashed.

That doesn't look similar. As you surmised in that bug, that was caused by a stack overflow when running the generated code. This is an out of memory crash.

From what I've seen in allocation graphs so far, this issue is primarily caused by the wasm compiler using excessive memory (like multiple GB in various metadata data structures) during code generation. There has been a lot of work in that area recently (e.g. #307389, #308158, #307107, #307990, #307686, #307551, #304810). I'm trying to verify whether this issue still persists after those fixes.

[Ben Nham]

I can see that after applying all of 306945@main, 307471@main, and 307660@main (bugs 307107, 307686, and 307990), the memory footprint of this particular workload drops well below the out of memory kill threshold. These changes are already in trunk.

I'm going to dup this to bug 304810 since it seems like we are using that bug as an umbrella for these WASM compilation optimizations.

[Ben Nham]

*** This bug has been marked as a duplicate of bug 304810 ***