Viewer on Windows leaking native memory

GroupDocs.Viewer Product Family
1

When rendering html views of documents it continuously leaking native memory.
Heap is ok, metaspace is ok. Only applies when rendering, i.e. not when documents already rendered and reading from cache.

Windows server 2012 r2, also confirmed on Windows 2016
JRE 1.8.0_152

Reproduced by the attached code.

doc-renderer-debug.zip (7.5 KB)

Run configuration
-Xmx512m -Xms512m -XX:MaxMetaspaceSize=512m

Resulted in:
memory-leak.jpg (16.1 KB)

Ended up around 2gb before exited.

2

@dalbrekt,

Thanks for using GroupDocs.Viewer for Java and sharing your concerns with us. Would you please share with us some sample documents for which you are getting this issue? We look forward to hearing from you.

3

This is a consistent behavior for any of the documents we been rendering (html).
Here is a document set that you can use and try to reproduce the issue.

Documents

https://dolphinsoftware-my.sharepoint.com/personal/tony_dalbrekt_seal-software_com/_layouts/15/guestaccess.aspx?docid=173c299be9c224f3e93c4a58defaff112&authkey=Ac33T-f8bwvrCopBhB5D7Ew&e=e320849761b64de1a37ed7a31da5d47f

FYI we are on version 17.2.0.

Thanks!

4

@dalbrekt,

Thanks for providing the required details. Please spare us some time to prepare your mentioned environment that is required to investigate the issue. We shall appreciate your patience and cooperation in this regards.

5

@dalbrekt,

Thanks for your patience. We have investigated your reported issue in your mentioned environment but unable to reproduce it for the random documents. Please watch here the memory consumption during the rendering of Cisco State Cooperative Contract.pdf document. You can download the sample application that we used to render the documents from here. You can test the provided sample application in your environment to check the results. Following are the visual representation of the heap and metaspace used for the rendering of some random documents that you provided us in the previous post.

6

Tested but it’s hard to tell by just running one document and where the content is of images only.

I made some modifications to be able to render all documents in a folder. Ran the test with the whole document set I provided from the command line (Xmx512m) and ended up with 1.5gb memory foot print just before completion.

memory-leak.jpg (25.7 KB)

Please run this test and let me know the outcome.

  • Download the project https://dolphinsoftware-my.sharepoint.com/personal/tony_dalbrekt_seal-software_com/_layouts/15/guestaccess.aspx?docid=0c38f06730f3744539502af5cedc97bae&authkey=ATlWXcKPc4mbPaRmCK17VFg&e=e5f6cd4928234d7abd72eb5606c81c07
  • Copy all documents I posted previously to the docs folder in the project root.
  • Build project > mvn clean package
  • Copy the license file to the project root
  • Start extraction > java.exe -Xmx512m -Xms512m -XX:MaxMetaspaceSize=512m -jar .\target\SampleViewerApp-0.0.1-SNAPSHOT.jar

Regards,
Tony

7

@dalbrekt,

Thanks for providing the detailed information. We are able to see maximum 1248 MB memory consumption while rendering the documents using your provided application (see this). We are further investigating the scenario and will keep you informed in case of any updates.

8

FYI! We have now also confirmed the memory leak in the latest release 17.5.0.

memory-leak-17.5.0.jpg (25.1 KB)

Can you please give me a progress report regarding the bug tracking?

9

@dalbrekt,

Thanks for checking the issue with the latest version. The issue is already under investigation. As soon as we have any useful information for you, we’ll inform you here. We would appreciate your patience and cooperation in this regard.

10

Hi.
This is a very serious bug so I assume you have someone working on it.
Can you please give me a progress update on this?

11

@dalbrekt,

Thanks for coming back to us. The issue is currently under investigation. As soon as we have any updates, we’ll share that with you. We appreciate your patience and cooperation.

12

Hi.
Now it’s been over a week since last contact and still no progress report.
It’s worrying us that you don’t give this more attention considering it is core functionality and the component is more or less useless if this is not fixed.

Can you please give us an estimate of when this will be fixed.

Regards, Tony

13

@dalbrekt,

Thanks for coming back. As per the latest updates, the issue is still under investigation. We’ll also check if we can have some progress updates for you. In case you want to increase the priority of this issue, you can avail the Priority Support as well.