[BUG] Crashes on iOS

[scambier]

Problem description:

Omnisearch causes an Obsidian crash on iOS

Your environment:

• Omnisearch version: 1.7.8
• Obsidian version:
• Operating system: iOS
• Number of notes in your vault (approx.):
• Other plugins that may be related to the issue:

[scambier]

The PDF indexing is disabled on iOS until a fix is published.

If anyone with an iOS device wants to volunteer for testing and reporting, I can make some customs builds. If someone wants to work on a PR, I'll happily guide them, too.

[bramses]

A few initial thoughts:

AFAIK Web Workers aren't fully supported on iOS devices (see example here, or here or here) natively which might cause errors in

obsidian-omnisearch/src/lib.rs

Line 8 in 342cdab

pub fn extract_pdf_text(arr: Uint8Array) -> Result<String, JsError> {

PDF.js has had trouble recently on iOS: mozilla/pdf.js#15543

I couldn't find where the normal indexing step is, but perhaps the PDF indexer is competing for resources?

[scambier]

@bramses thanks for your references 👍

I guess the crashes are caused by a too high memory usage. As simple as that. There's not a single root cause. Omnisearch uses a lot of memory during indexing/refreshing. It eventually goes back down, but all documents still need to live in RAM to update the search index when users modify their notes 2022-12-03: this is no longer true, so it frees some memory and cache space.

Using my test vault as a reference: 1300 notes + 4000 PDFs (several novels)

• Startup RAM: ~250MB
• Peak memory uses: ~700MB when indexing PDFs, ~1300MB when updating the IndexedDB.
• Settled: ~550MB

Without the PDFs:

• Startup RAM: ~250MB
• Peak memory use: ~400MB when updating the IndexedDB.
• Settled: ~270MB

Honestly at that point I'm kinda fed up with this. I don't own an iOS device, and even if I did it won't allow me to diagnose anything. It's all trial and error and I think the solution will be to disable Omnisearch entirely to avoid crashes.

[scambier]

Update: the culprit is most likely the cache (de)serialization. I disabled the cache for iOS devices, and it looks like it stopped the crashes for at least one user. While I'm not satisfied with this solution, all other workarounds I tried were not better, and would have made cache management more complex.

If your device keeps crashing, please add your input here with as much information as possible (number of notes, pdfs, copy of the console log). Thank you.

[bramses]

@scambier great find! These problems at this scale are very complex -- and break often, I imagine it will always be a WiP as devices evolve with time. I don't have any PDFs in my vault, but if I come across this bug, I'll follow up here. Thank you for the fix!

[scambier]

Update: I removed PDF indexing for all mobile devices (incl. Android), which should also reduce the risk of a crash. Even if it works technically, it's not worth the headaches.

I prefer to propose a slightly inferior, but stable version of Omnisearch mobile, than something unstable.

[scambier]

I don't think I can do much more for this issue, since the crashes are more than likely caused by memory consumption. I'm doing my best to keep it as low as possible without compromising performances too much, but Minisearch does use a lot of RAM 🤷‍♂️

[carlosbaraza]

Mobile is a pretty key part of the Obsidian experience for many users. It seems that a search plugin that "just works" should probably work on iOS/Android, so I imagine we should not discard it yet. Building a project like this is a lot of work and I genuinely appreciate it.

A few ideas to support mobile:

• Could it be possible to index more slowly without consuming so many resources?
• Could we define a path to store an export of the IndexedDB? A few libraries claim to help doing this export (e.g. indexeddb-export-import). This could be done in the desktop device, and mobile could restore the backup. Inicially OCR could be disabled in mobile, but at least some PDFs would be searchable.
• An alternative could also be to split the index generation in two parts:
  1. Extract the OCR into files. An option could be given to store them in the same path than the original PDF.
  2. Use the extracted OCR files as the source of the index
  3. Only run OCR for files that don't have already a file generated with the OCR.
  4. In mobile, the OCR wouldn't even need to run, just the indexing into the database, like it currently does.

I believe the last one could be the most flexible, and full OCR would not need to be done on each device.

[scambier]

@carlosbaraza

Mobile is a pretty key part of the Obsidian experience for many users. It seems that a search plugin that "just works" should probably work on iOS/Android, so I imagine we should not discard it yet.

I agree, and believe me when I say I'm not happy with this. But I've already spent a lot of time on this, and as I don't own an iOS device myself, I can't do very specific tests and rely on benevolent users.

As far as I understand, there are 2 causes for the crashes:

• Indexing a "big" vault makes Obsidian crash after a few seconds.
• Loading a "big" cache makes Obsidian crash instantly at startup. It looks like some vaults can be indexed correctly, and only the cache loading triggers a crash.

The 2d point makes me think it's an iOS security trigger: loading the cache does not consume more memory than indexing, but consumes it much faster. I also disabled caching on iOS, because if Obsidian crashes at startup, it's extra difficult to fix for non-technical users.

About your suggestions - if a developer with an iOS device is willing to tackle this, I'll be happy to guide them and answer their questions.

Text extraction is only tangentially related, though using metadata files instead of the IndexedDB is an excellent idea.

[carlosbaraza]

I own an iOS device, although I'm not sure I'll have enough time to dig into the problem. Maybe the last week of the year I get some time. Do you have a contributing guideline? How do you install the plugin under development on iOS to test it out?

About owning an iOS device. If you own a Macbook, maybe you could run the Xcode iOS Simulator

[scambier]

There's a basic contributing guide but it's pretty superficial and focused on UI and the search itself.

The cache loading/indexing starts here:

obsidian-omnisearch/src/main.ts

Line 120 in ed646eb

async function populateIndex(): Promise<void> {

Indexing into minisearch engine is done here:

obsidian-omnisearch/src/search/omnisearch.ts

Line 97 in ed646eb

public async addFromPaths(paths: string[]): Promise<void> {