Is this issue specific to the Next.js repo, or could this also be replicated using the basic examples in this repo?

Unfortunately my ability to troubleshoot this is limited. I do not own an iOS device and Browserstack (a service that allows us to connect to iOS devices remotely for testing purposes) has not yet added iOS 17.

It appears that a similar error existed for the iOS 15.4 beta, so it seems at least possible that this is an issue on Apple's end that will be resolved before the release. https://forum.unity.com/threads/fatal-error-with-webgl-running-on-15-4.1244374/

Thanks for the quick response! Using a slightly modified demo.html (just replaced the local <script> tags with the CDN) I was able to reproduce this same error.

Totally possible that it may be an Apple issue, and will keep an eye out on future betas to see if this issue still exists. Not sure if you're on a Mac, but you may be able to use the iOS simulator in an attempt to reproduce this as well.

Either way, figured I'd open an issue to give insight to others running into this issue/notify you guys as I have very little knowledge of the inner workings of Tesseract & WASM :)

Makes sense, thanks for reporting. Can follow up closer to the release of iOS 17.

Has there been an investigation and resolution on this? I am also getting an error on iOS 17 -

RunTimeError: call_indirect to a null table entry (evaluating .....TessBaseAPI_GetUTF8Text_0=b.asm.Kd).apply(null,argumnets)')
using ver 2.2.0. But I think it happens in the latest version as well

@MayuraRam Tesseract.js v2 was released in 2019 and is depreciated/unsupported. That version has poor performance and many bugs including (if I recall correctly) some specific to iOS. Therefore, I would strongly advise updating to a recent version. A guide for updating to the latest version can be found in #771.

Regarding the iOS 17 issue, Browserstack did recently add iOS 17, so I was able to test using the demo site. Everything worked as expected. Therefore, I think that my theory above (that this is an issue on Apple's end with early beta versions of iOS) was correct. Along those lines, you should check if you are using the latest version of iOS 17, and if not, update to the latest version.

Thanks @Balearica - What's the best way to get "tesseract-core.wasm.js" corresponding to the latest release?

Thanks @Balearica - What's the best way to get "tesseract-core.wasm.js" corresponding to the latest release?

If you do not set the corePath argument, the correct version of Tesseract.js-core files will be automatically downloaded from the jsDelivr CDN. If you want to host the files locally, you can download them from the Tesseract.js-core GitHub releases page here or the NPM package here.

Important note: in previous versions of Tesseract.js, corePath would be set to tesseract-core.wasm.js. This should not be done anymore. Instead, corePath should be set to a directory containing both tesseract-core.wasm.js and tesseract-core-simd.wasm.js. This allows Tesseract.js to take advantage of SIMD instructions for supported devices (all modern desktop browsers and Android phones). This literally cuts recognition times in half.

@Balearica - I am running iOS 17 beta on an actual iPhone. I am running tesseract.js-core-4.0.4\tesseract.js-core-4.0.4\examples\web\benchmark\benchmark.wasm.html from the latest release package mentioned above. I am getting the same error - Unhandled Promise rejection: RuntimeError: call_indirect to a null table entry (evaluating'(Vf=b._emscripten_bind_TessBaseAPI_GetUTF8Text_0=b.asm.Kd).apply(null, arguments)')

seeing the same issue on Chrome when running on iPhone with iOS 17 beta.

How could I resolve this issue? Thanks for your help!

@MayuraRam Can you please confirm the following?

1. Does this demo site run on your device or throw an error?
   1. This is what I tested earlier when I found that Tesseract.js worked with an iOS v17 device, so if this fails on your device that would help to narrow down the potential causes
2. Exactly which version of the iOS 17 Beta is your device running?
   1. There have been multiple beta builds released.
   2. Based on the information above, it appears that some but not all are problematic--so knowing the exact version is necessary to proceed

The demo site works on Safari on the device with iOS 17.0 (21A329) - Downloaded and installed today. Does the demo site use tesseract-core.wasm.js? You mentioned "Tesseract.js" - does this load the wasm version?

The demo site I linked loads the latest version of the .wasm.js build from the jsDelivr CDN. Unless a cached version was being used, that means https://cdn.jsdelivr.net/npm/tesseract.js-core@v4.0.4/tesseract-core-simd.wasm.js would be downloaded.

Therefore, as your device was capable of running recognition using this .wasm.js file, I am inclined to believe there is something going on with the particular example code you are running. To clarify, does the code in your project use the functions in this repo (Tesseract.recognize or worker.recognize) or does it use Tesseract.js-core directly? If the former is true, then I would stick with the examples in this repo (Tesseract.js) rather than the Tesseract.js-core repo, which uses lower-level functions.

Also, for both sites (the demo I linked and whatever you are running) I would be sure that the cache/local files are cleared. When there is an issue that cannot be replicated, cache is a common cause.

Thanks @Balearica - I verified that the demo code is downloading https://cdn.jsdelivr.net/npm/tesseract.js-core@v4.0.4/tesseract-core-simd.wasm.js. This is the code that is not causing a problem.

I am trying to use Tesseract.js-core directly - as in the sample code here - https://github.com/naptha/tesseract.js-core/blob/master/examples/web/benchmark/benchmark.wasm.html. It does not use Tesseract.recognize nor worker.recognize.
I use tesseract-core.wasm.js directly and host them locally.

I tried this sample code - https://github.com/naptha/tesseract.js-core/blob/master/examples/web/benchmark/benchmark.wasm-simd.html as well and am seeing the same issue. With this I use tesseract-core-simd.wasm.js directly

I am still seeing the same issue when loading directly.

Given you confirmed Tesseract.js-core v4.0.4 is being downloaded and run within the example code I linked, the errors you are describing must be specific to your project setup, server configuration, or the particular example code you are using.

However, just to make sure, I created a minimal repo based on one of the Tesseract.js-core examples and hosted it at https://tesseract-js-core-example.pages.dev/. I tested on iOS 17, and recognition worked as expected. The repo can be found here. Therefore, between this and the earlier tests, I think we can conclude that iOS 17 is compatible.

In general, if you use low-level Tesseract.js-core functions rather than the functions in this repo, that is not something we can offer much documentation or support for. The Tesseract.js-core repo exists separately in case advanced users/developers want to build their own version of Tesseract.js with custom wrapper functions or a forked version of Tesseract.

@Balearica - Thank you for taking the time to setup the sample. That helped me debug. I was using a jpg image (test.jpg) for my testing. Looks like this jpg image is causing the issue on iOS 17 beta. I tried the image with https://tesseract-js-core-example.pages.dev/. There is no problem with other test images, but test.jpg image causes the issue. I then took a screenshot of the image on the iPhone and saved the image as screenshot_2.png. When I use this image I see no problems. I am trying to understand why this could be happening.
error_images.zip

How can I learn more about why this particular image is causing an issue?

Many images fail on MacOS with Safari Tech preview with the sample provided at " https://tesseract-js-core-example.pages.dev/" . There is a commit on Webkit which could be connected with the issue.

@MayuraRam To clarify a couple points above--

There is no problem with other test images, but test.jpg image causes the issue

Do all .jpg images fail on iOS 17 or is the one you attached special?

Many images fail on MacOS with Safari Tech preview

Are the images that fail for MacOS + Safari tech preview the same images that fail on iOS 17? (E.g. does the .jpg image you attach fail on MacOS + Safari tech preview?) If so, are the error messages the same?

Reporting the problematic image from the .zip archive here.

@Balearica - What I mean by "There is no problem with other test images" - the test images at https://github.com/naptha/tesseract.js-core/blob/master/examples/web/benchmark - meditations.jpg, testocr.png and tyger.jpg

Re: "Are the images that fail for MacOS + Safari tech preview the same images that fail on iOS 17? (E.g. does the .jpg image you attach fail on MacOS + Safari tech preview?) If so, are the error messages the same?"

yes - test.jpg fails and the error message is the same.

Let me know if you encounter this issue on any images that are not .jpg. I'm wondering if the .jpg format is relevant or a red herring, given that the error messages are associated with recognition rather than anything image-related (the images are already processed into an internal format by the time recognition is called).

All in all, this is a bizarre issue. I am limited by not owning Apple devices, and was unable to replicate this using the Linux version of webkit in the repo you linked. Unfortunately, while the error can be replicated on the Browserstack devices we can connect to virtually in the sense that recognition does not run, they are not producing the error messages. I may be able to get a hold of an Apple device later in the week.

@Balearica - attached Tyger.png has the same issue. Let me know if I can provide any other information that could help debug the issue. I think the problem is in this function - function UTF8ArrayToString(u8Array, idx, maxBytesToRead)

I think the problem is in this function - function UTF8ArrayToString(u8Array, idx, maxBytesToRead)

Can you clarify what this is based on? I am not seeing a function of this name anywhere in the codebase.

@Balearica Apologies - That function is in the earlier version of tesseract-core.wasm.js, which I have been trying to debug as well. I will try to investigate the current (v4.0.4) tesseract-core.wasm.js.

@aw-0 @MayuraRam Can somebody explain their exact process for producing the RunTimeError: call_indirect to a null table entry message? For the devices I have tested on using BrowserStack, with the example site I created for this issue (https://tesseract-js-core-example.pages.dev/), no such message was printed. The images simply failed to recognize, but nothing informative was printed to the console. My failure to produce any informative error message is a significant roadblock to my ability to troubleshoot this issue.

@MayuraRam It looks like this issue is caused by the Legacy model. As background: Tesseract includes 2 models--LSTM and Legacy. By default, the LSTM model is used. If the LSTM model fails to produce a result it believes is valid (which occurs for a small minority of words), the Legacy model attempts to recognize that word.

This behavior appears to be why the issue only occurs for specific images. For many images, the Legacy model will never be run using default settings--however for some images it will be for specific words. As a test, I created an additional 2 versions of the test site:

1. This version always uses the LSTM model (the Legacy model is disabled in the build):
   1. https://tesseract-js-core-example.pages.dev/lstm
2. This version always uses the Legacy model:
   1. https://tesseract-js-core-example.pages.dev/legacy

[Note: I added some additional debugging messages to the Tesseract.js-core builds used in these pages, so you may notice additional messages being printed to console. The original page (https://tesseract-js-core-example.pages.dev/) still uses the release build.]

My testing indicates that unlike the earlier tests (where specific images failed but others were recognized correctly), the LSTM-only version always runs properly and the Legacy-only version always fails. Please confirm this is true of all of your test images.

Unless anybody identifies images that contradict the above conclusions, the fix I will prioritize is disabling the Legacy model by default, which is already planned for Version 5 (see #820). While an ideal fix would allow both the Legacy and LSTM models to run on iOS 17, there is no telling how long this would take to troubleshoot (much less fix).

@Balearica - I have verified that the images that were failing earlier are now passing with LSTM-only on an iPhone with iOS 17.0.1 (and iOS 17.0). In addition (FYI): When I ran images that were working with the default LSTM + Legacy, they fail with Legacy only.

Thank you for identifying the location of the issue and providing a work around. Could you please provide instructions on how to build "tesseract-core.wasm.js"? I could try to build a LSTM-only version with the files tagged "[v4.1.2]"

@MayuraRam Can you clarify whether your are able to produce the "RuntimeError: call_indirect to a null table entry" with any of the example pages, and if so, what your process is?

I will release an official version of Tesseract.js-core that includes a LSTM-only build in the next few days. Will update this issue once that happens.

@Balearica - Re your question:
Can you clarify whether your are able to produce the "RuntimeError: call_indirect to a null table entry" with any of the example pages, and if so, what your process is?

Yes - this example fails with iOS 17.0.1 - examples/web/benchmark/benchmark.wasm.html with "RuntimeError: call_indirect to a null table entry"

Setup the iPhone for debugging by going to settings-> Safari-> Advanced. Scroll down to find "Web Inspector" and turn it on. Open Safari on a Mac Book and go to Safari->Settings. Select "Advanced" tab and turn on Show Develop menu in the menu bar. Then connect the iPhone to a MacBook. From Develop menu on MacBook Safari you should see the connected iPhone. Run the example pages on an iphone with iOS 17.0 ( and now iOS 17.0.1). Then look at the console from develop menu on the MacBook. Here's a good description.

@MayuraRam By "the example pages" I mean the example pages that we've been working with over the last week (listed below). Do you observe the "RuntimeError: call_indirect to a null table entry" message when you use any of these pages?

1. https://tesseract-js-core-example.pages.dev
2. https://tesseract-js-core-example.pages.dev/lstm
3. https://tesseract-js-core-example.pages.dev/legacy

@Balearica Please see below:
https://tesseract-js-core-example.pages.dev/ - See "RuntimeError: call_indirect to a null table entry" on some images and not on others with iOS 17.x
https://tesseract-js-core-example.pages.dev/lstm - Do not see the message at all, with any of the sample images with iOS 17.x
https://tesseract-js-core-example.pages.dev/legacy - See the message on iOS 17 with all of the sample images with iOS 17.x. And don't see the message with Chrome on Windows 11

@MayuraRam While Tesseract.js v5 has not been released yet, if you only use Tesseract.js-core you should can use a build found in that repo or in the Tesseract.js-core v5 beta release on npm.

The files for the LSTM-only build would be tesseract-core-simd-lstm.wasm.js (should be served to the vast majority of users) and tesseract-core-lstm.wasm.js (served to the minority of users that have old browsers that lack SIMD support).

Closing this issue as Tesseract.js v5 has been released, which should be fully compatible with iOS 17 by default (as it only uses the LSTM model by default). If any users encounter issues with iOS 17, upgrading to v5 should resolve.

I will open a new Git Issue regarding how the Legacy engine is still not compatible with iOS 17, however I doubt many users use the Legacy model, so that is a much smaller issue.

@Balearica - Thank you for the quick resolution.

To close the loop on this--this issue appears to be fixed by Apple in iOS 17.2 (see #867). Therefore, the fix described above (avoiding the Legacy model) is only relevant for iOS 17.0 and 17.1. If somebody can produce this error on iOS 17.2 onward, please open a new issue.

Yes - we have verified this as well.