Getting an Uncaught RuntimeError: memory access out of bounds exception when opening another PDF in the WebViewer

Technical Support
1

Product:
PDFTron Webviewer
Product Version:
8.4.1

Please give a brief summary of your issue:
Uncaught RuntimeError: memory access out of bounds when opening a PDF in web viewer

Please describe your issue and provide steps to reproduce it:
(The more descriptive your answer, the faster we are able to help you)
The issue has come up after we implemented preloading to try and make the web viewer a little faster in our Angular application. The issue is caused when a previous PDF hasn’t been closed, and attempting to open a new one causes the memory out of access exception.

I’ve tried calling the .close() functions as well as the .dispose() functions before and after a document has been loaded, and the issue still seems to persist. Is there a reason why these two functions wouldn’t close the previous PDF that has been opened?

Any help on this is greatly appreciated!

2

Hi @mohammad.mansoor,

How are you pre-loading the viewer? Have you had a chance to go over our guide on this?

If you are hiding the element with display: none this may cause issues:

Don’t use “display: none” to hide the element
This causes issues with iframes and web workers. Use “visibility: hidden” or “height: 0; width: 0;” instead.
You may see an error like “memory access out of bounds”, NS_ERROR_FAILURE or “getComputedStyle(…) is null”

Best Regards,
Armando Bollain
Software Developer
PDFTron Systems, Inc.

3

Yes, we followed the guide when implementing the preloading and also avoided using display: none; when hiding the WebViewer between documents. It seems like the previous document hasn’t closed properly, so when a new one is added the browser runs out of memory, even after explicitly calling the functions to do so.

Also, this seems to only be occuring on Chrome. When running the WebViewer in Firefox I run into no memory issues.

4

Hello @mohammad.mansoor,

Since this is only happening in Chrome, would it be possible for you to try forcing the backendType to be ems?

The backendType can be passed as a WebViewer initialization option:
https://www.pdftron.com/api/web/global.html#WebViewerOptions

This is to rule out any potential issues with WASM-threads. Also please ensure you are on the latest version of Chrome.

If this does not resolve the issue, can you create a sample project where we are able to reproduce this issue?

Best Regards,
Armando Bollain
Software Developer
PDFTron Systems, Inc.

5

We verified the backend type is set to esm. Our customers are viewing documents all day long. This seems to happen after some amount of time. They are on the latest version of chrome 103.

What can we do to mitigate/prevent this?

6

Hi @john @mohammad.mansoor,

There was a performance fix made in a recent release of WebViewer. Could you update to 8.7 and see if the issue is resolved?

If the issue persists we would need the following to look further into this:

  1. Performance graph from Chrome’s debugging to determine if there is a memory leak related to WebViewer (in case the leak is coming from a separate component not related to WV)
  2. Sample project where this issue can be reproduced

Additionally, is this issue being reported by users on 32 bit Chrome? Or does this also affect 64 bit users.
Best Regards,
Armando Bollain
Software Developer
PDFTron Systems, Inc.