Cannot initialize worker because of out of memory error on WASM

[fmonpelat]

Hi, im currently facing an issue on mobile phone using chrome 32 bits (with 64 bits works fine):

• Device: Samung Galaxy S20 FE
• OS: Android 12
• Browser
  Google Chrome: 108.0.5359.79 (Official Build) (32-bit)
  Revision: 5194e1e1073e30a8fc93c72c2aee4bc572f5b07a-refs/branch-heads/5359_61
  OS: Android 12; SM-G780F Build/SP1A.210812.016
  JavaScript: V8 10.8.168.21

Library Tesseract.js installed using npm ("tesseract.js": "^4.0.0")

When using tesseract.js from react app sometimes hangs up on initialization, changing line 40 in src/worker-script/index.js with:

Core({
      TesseractProgress(percent) {
        latestJob.progress({
          workerId,
          jobId,
          status: 'recognizing text',
          progress: Math.max(0, (percent - 30) / 70),
        });
      },
    }).then((tessModule) => {
      TessModule = tessModule;
      res.progress({ workerId, status: 'initialized tesseract', progress: 1 });
      res.resolve({ loaded: true });
    }).catch((err) => {
      console.error(err);
      res.reject(err.toString());
    });

will reveal that there is a problem with memory its rejecting with message:

RuntimeError: Aborted(RangeError: WebAssembly.instantiate(): Out of memory: Cannot allocate Wasm memory for new instance). Build with -sASSERTIONS for more info.

[Balearica]

Please edit your issue to include what version of Tesseract.js you are using. I'm assuming it's the latest version, however it's good to explicitly document and doing so creates a better record for when issues are searched in the future.

[fmonpelat]

yes, sorry about that i completly forgot, maybe i can build tesseract.js-core with assertions enabled to see whats going on, do you have a pre built files with assertions?

[Balearica]

I tried running Tesseract.js using Chrome on a Samung Galaxy S20 using Browserstack, and it worked correctly. Several follow-up questions are below that may help troubleshoot further.

1. When you say "with 64 bits works fine", are you trying different browsers on the same device? Or is the 64-bit browser on a different device?
2. To confirm, this issue sometimes but does not always occur?
   1. If so, does it sometimes happen the first time you open Chrome (after closing all other pages and completely restarting--not just minimizing), or does the first use always work?
      1. If it does not occur the first time, then that is an indication that this is due to a failure to terminate previous instances using await worker.terminate() or await scheduler.terminate().

Regarding building with assertions, I do not have an existing build that does this, and despite the error messages above am skeptical that this would be useful. Presumably the Browser is not allowing Tesseract to allocate the memory it needs. I don't think that building with assertions would help explain why that is.

[fmonpelat]

Ok i should explain further (sorry about not being more specific before). So i began testing tesseract and saw that my webapp on react didn't behave in mobile as it was on my mac m1. I checked that tesseract.js wasn't initializing and was stuck (didn't get the "progress": 1 from worker).
At first i didn't know what was happening so added the catch, after that that out of memory error came up.
I googled the error and saw this url https://github.com/emscripten-core/emscripten/issues/16955 i know its not related at all, its another repo, but maybe its related somehow. i'm running out of options...
I checked the phone's browser and saw that it was chrome 32 bit (S20FE). After this i installed brave and checked it was 64 bit, and give it a try, it worked ok on every test i did (initialization was ok). This is the brave browser spec on the same device (always on Samsung S20 FE):

Brave:	1.46.134 Chromium: 108.0.5359.94 (Official Build) (64-bit) 
Revision:	713576b895246504ccc6b92c2fb8ce2d60194074-refs/branch-heads/5359_71@
OS:	Android 12; Build/SP1A.210812.016
Google Play services:	SDK=12451000; Installed=224814045; Access=3p
JavaScript:	V8 10.8.168.21

So to answer your questions:

1. Yes i tried brave on the same mobile device and it was a 64 bit browser it worked fine.
   I tried using another samsung phone in a A52 and worked fine the first try in 32 bit chrome when retrying it threw the same error "out of memory error".
2. This issue ocurrs sometimes
   this is the useEffect on react for creating the worker:

useEffect(() => {
    async function initOCR() {
        Tesseract.setLogging(true);
        ocrRef.current = await Tesseract.createWorker({
          langPath: '..',
          gzip: false,
          cacheMethod: 'none',
          logger: (m: string) => console.log(m),
        });
        await ocrRef.current.loadLanguage('ocrb_fast');
        await ocrRef.current.initialize('ocrb_fast');
        await ocrRef.current.setParameters({
          tessedit_char_whitelist:
            '0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz<',
        });
    }
    initOCR();

    return () => ocrRef.current.terminate();
  }, []);

BTW, Thanks @Balearica for your answers

[Balearica]

The issue you link to on the emscripten page is directly related, as we use emscripten to compile Tesseract to Webassembly. The issue is just that it's a generic error that doesn't help much in explaining why your device is not showing enough memory.

A few follow-up questions:

1. Does refreshing the page make it work again (if only temporarily)?
2. How many times does your app create a new worker?
   1. If you aren't using parallel processing, you should only need to create a worker once and then it can be used for all
      recognition jobs.
3. Are you running with devtools open?
   1. If so, try again without devtools
      1. Devtools can prevent Chrome from properly clearing memory which can lead to this error

[fmonpelat]

Ok, i thought that it wasn't related because the error said something about Decoder.js in the error described by that issue on emscripten.

1. No it does not, every test with S20FE doesn't initialize always with the same error. On other phones its aleatory if it works.
2. The app creates only one webworker i think i followed the example and i'm creating the webworker as the useEffect code in the last message.
3. No, i'm not using devtools as i saw in an issue that GC is not being called.

I think that tesseract.js-core is using a lot of modules and maybe some of them has a big memory footprint, so when it asks for a big chunk of memory it fails, this shouldn't be an issue with 64 bits because the virtual page address is bigger (quoted from the answer on emscripten before).
I checked this other repo to check if it is something from tesseract code but it works ok: https://github.com/robertknight/tesseract-wasm
I know the error i described is too generic but is something to be considered when using tesseract.js-core, i completely coded only with tesseract.js-core without the worker of tesseract.js and the same issue happened, should i comment this out in the tesseract.js-core repo?

[Balearica]

Is it possible for you to post the exact repo you are using along with any instructions for running?

As stated above, I previously tried running Tesseract.js with Chrome 32-bit on a Galaxy S20 and it ran as expected. Today I tried running on Chrome 32-bit on a Galaxy S6, which is a much older device (released Spring 2015), and that also ran as expected. Therefore, I would need access to your site/repo to do anything further, as I am unable to reproduce the issue without it.

[Balearica]

Also, regarding "app creates only one webworker i think", I would confirm this by adding a console.log statement within the initOCR function to confirm it only runs once.

[fmonpelat]

yes, i can try to reproduce the same error on a new repo, but give me a few days. The function that makes the worker happens one time so it's creating one web worker. Thanks for your answers

[Balearica]

Is there any follow-up here? If not I will close as stale.

[fmonpelat]

sorry couldn't have the time to create a working demo that reproduces the error, when i have time i will make a new issue. thanks @Balearica