Memory leak in WPF with PDF Viewer control when navigating away from the page

[Rhyme]

hello,

I recently came across a memory leak issue while using the WPF framework in conjunction with the PDF Viewer control. Even after calling the PdfViewer.Unload(true) method, the control does not get garbage collected when navigating away from the page, resulting in continuous memory growth and ultimately leading to memory leaks.

I have attached a sample code snippet demonstrating this issue. It would be great if someone could provide some insights or solutions to this problem. I have already tried explicitly calling the unload method and setting the control to null, but the memory is still not released.

Any help or suggestions would be greatly appreciated.

Thank you!

Attachment: Syncfusion_PDF_536aac0f.zip

[Krithika Ganesan]

Rhyme, With the provided details,  “there is minimal memory leak occurs for PdfViewer control” can be reproduced on our end. We will analyze and update the further details on May 26, 2023.

[Rajavignesh BalaSankar]

Rhyme, on further analysis, we found that the process memory is alone increased constantly as it consumes the memory for the entire project including debugging. But the Snapshot memory shows the memory consumed by the code used in the project. So, the process memory will usually be high that the snapshot memory. You can also refer the below MSDN forum for more details,

https://social.msdn.microsoft.com/Forums/en-US/fb5517b3-e1f4-4fc2-be0f-1872ce41f5c3/snapshot-memory-vs-process-memory?forum=vsdebug

Also, from your sample, we came to know that you are disabling both the toolbars in PdfViewerControl. As you are disabling the toolbars, you can use PdfDocumentView instead of PdfViewerControl to optimize the memory better because the PdfDocumentView won’t contain the UI elements such as buttons, panels,etc…

[Rhyme]

Thank you for providing me with these optimization suggestions. I have noticed that in my production environment, navigating multiple times using the PDF viewer component leads to memory leaks and program freezes, while the demo program does not encounter these issues. Could you please provide me with more optimization suggestions specifically for the PDF Viewer?

[Rhyme]

Hi, 

I am sure that the memory occupied by the pdf viewer is not freed when I leave the page, is there any way to free up the occupied memory?

[Rajavignesh BalaSankar]

Rhyme, from the sample and the snapshot that you have provided in above responses, we found that you are using a 32-bit environment. In 32-bit environment, the used memory can’t be cleared normally even if we force GC clear, it won't be cleared. We have also confirmed this by reporting the issue in the MSDN WPF forum earlier for the similar issue.
https://github.com/dotnet/wpf/issues/1082#issuecomment-608326285

[Rhyme]

Thanks for your help, I have solved this problem using other means

[Krithika Ganesan]

Rhyme, Most welcome.

[Rhyme]

Hello everyone, unfortunately, I've encountered yet another memory leak issue. This time, it's related to NTHeap. I conducted a stress test in my program by continuously opening and returning a PDF file. After approximately forty minutes, my program started crashing. I generated a dump file and analyzed it. I discovered that even though I called the Unload(true) method when exiting the page, the images from pdfium were not properly cleaned up. As a result, there are 644 2MB bitmaps on my unmanaged heap that haven't been released, occupying all of my program's unmanaged memory.

Dump analysis showing objects not properly garbage collected leading to an access violation:

Unreleased images on the unmanaged heap:

Functions that may be causing the issue:

Could you please assist me in resolving this problem?

[Krithika Ganesan]

Rhyme, With the provided details, the reported issue “AccessViolationException occurs when we continuously create PdfViewer” can be reproduced on our end. Issue gets reproduced on our end in 25 minutes with the PDF we have. It will be helpful for us to investigate further if you share the PDF from your end.

We have an NDA (Non-Disclosure Agreement) in place with our customers and we maintain the confidentiality of the information disclosed by our customers to us. Therefore, any documents shared with Syncfusion will only be used to replicate the issue and will not be shared with anyone else. So kindly share the original input document or share the input document after removing confidential information.

We will analyze and update the further details on June 9, 2023.

[Krithika Ganesan]

Jine, the reported issue is not related to memory.  This issue occurs when we are continuously loading and unloading PdfViewerControl, so image will be created continuously. So while we are creating the image continuously we are facing this issue. We will check on this and update further details on June 13, 2023.

[Rhyme]

I get it. Looking forward to your further results

[Rajavignesh BalaSankar]

Rhyme, when we continuously click the load and unload the pdf files in the PdfviewerControl, the unload function is triggered before the load function is completed. So, we suggest you enable the “Exit” button after the document is loaded in the PdfViewer. We have modified the sample that you have provided and attached below for your reference.

In the sample, we have disabled the “Exit” button initially and we have enabled it in the `DocumentLoaded` event of the PdfViewerControl so that the button will be enabled after the document is loaded. Now, when you click the ‘Exit’ button, the unload will work properly as the load function is completed. This will help you to resolve the reported issue.

Attachment: Syncfusion_PDF_Modified_bbe7d9db.zip

[Rhyme]

hi Rajavignesh, 

Thank you for your active cooperation. I have tested the modified program for an hour and it is currently running well. I will continue to ask you when I have questions. Thank you very much.

[Krithika Ganesan]

Rhyme, thanks for the update, please get back to us if you need any further assistance.