Steps to reproduce
- Create a vault of roughly 2,000 markdown files, 32 MB in total, with ordinary note density (headings, wiki links, list items; our vault averages about 115 cache elements per file, 128 bytes of metadata cache per element). No community plugins. Default core plugins.
- Open that vault on an Android device with a V8 heap limit of about 900 MB (observed on a Motorola moto g67, Android 16, build
motorola/naples_g_syse/naples:16/W2WIS36.43-92-5). We used Obsidian Sync to bring the files over, but Sync is not the trigger: the crash reproduces on every subsequent launch, long after Sync is idle. - Wait 9–10 seconds.
A synthetic vault should reproduce this without anyone’s private data: a script that generates ~2,000 files with a few headings, 10–20 [[wiki links]] to other generated files and some list items each. We can supply one on request; our measurements were made on the real vault and on a plugin-free copy of it.
Did you read and follow the Troubleshooting Guide ?
Yes. Clean vault copy, no community plugins, restricted mode, fresh app data. The crash is independent of plugins, of Sync activity and of any single large file (largest per-file cache is 0.4 MB).
Expected result
The vault opens; indexing takes a while on a phone, but completes.
Actual result
The renderer process dies on every launch. logcat shows the V8 heap limit being reached inside the DedicatedWorker thread of the sandboxed renderer, followed by a native crash of md.obsidian:
v8_oom.cc:49 V8 javascript OOM (Reached heap limit)
... SIGTRAP ... thread DedicatedWorker ... SandboxedProcessService
am_crash ... md.obsidian ... Native crash,Trap
Renderer memory sampled via /proc/<pid>/status during one launch (RSS / V8 heap, MB):
| t after start | RSS | V8 heap |
|---|---|---|
| 0 s | 92 | 13 |
| 2 s | 206 | 92 |
| 4 s | 235 | 143 |
| 7 s | 873 | 894 |
| 9 s | OOM, RSS 1.19 GB | limit ≈ 900 |
Three launches in a row crashed at the same point (23:03:15, 23:03:34, 23:03:53). The app shell process stays at 136–200 MB; the system low-memory killer is not involved.
The same vault on desktop (Windows, Obsidian 1.15.0, heap limit 4,192 MB), cold index of a fresh copy without plugins, renderer working set in MB: 142 → 620 at 17 s → sawtooth 441 / 487 / 606 / 537 → 279 stable after 50 s. Peak 631 MB. So the resident metadata cache is small (32 MB serialised for the whole vault, 430 MB heap with everything loaded); the problem is the initial indexing burst: files are parsed faster than garbage collection reclaims the intermediate objects, so the peak scales with vault size rather than with the final cache. On desktop the peak fits; on a phone it does not.
Confirming experiment: the identical set of files loads fine on the same phone when it arrives in portions. We created a new vault with the large folders excluded in Sync, let the small part index, then un-excluded sub-folders one at a time (7.9, 7.3, 4.7 and 6.3 MB). Every step indexed without a crash and the complete vault now opens normally — until the cache is invalidated (app update, re-link), after which the full burst returns.
Environment
- Obsidian Mobile 1.15.0 (396) on Motorola moto g67, Android 16, ~3.6 GB RAM, WebView V8 heap limit ≈ 900 MB.
- Desktop reference: Obsidian 1.15.0, Windows 11.
- Vault: 2,019 markdown files, 32 MB; no community plugins; Sync used for transport only.
Related earlier reports (same mechanism, different symptoms):
- File truncated on Obsidian crash (out-of-memory from reindexing triggered by typing) (memory during re-parse of large notes, moderator confirmed whole-note re-parse),
- Improve support for very large notes - markdown files (greater than 1 MB) and Renderer exits and window turns black while indexing large Markdown files (Obsidian crash) (mobile crashes during indexing),
- Obsidian crash at startup and restart (loop) - likely indexing parser OOM . Feature request with a proposed fix: see here.