Aspose.pdf does not release memory

Aspose.PDF Product Family
1

We find that Aspose.PDF leaks memory in production, but it is impossible to debug due to the obfuscation when viewing memory profiler snapshots.

In the following reduced example using Aspose.Pdf 25.6.1, there is a spike of memory usage when calling the document.Save method to save the document as a PDF.
In this example the size of the PDF is 12kb and memory usage spikes from 12mb to 102mb when calling the Save method.
This memory is never released.

Looking at memory snapshots it appears to be held in static objects by the Aspose library, but the names are obfuscated.

using Aspose.Pdf;

Console.ReadKey();

var pdfPath = @"C:\PathToFile\Test.pdf";
var xpsPath = DateTime.Now.Ticks + ".xps";

using (var document = new Document(pdfPath))
{
    document.Save(xpsPath, SaveFormat.Xps);
}

Console.ReadKey();
2

@tims-1

Cause

You are experiencing a memory leak when using Aspose.PDF, particularly during the document.Save method. This issue often arises due to static objects holding onto references that are not released, resulting in increased memory usage that does not decrease after the operation.

Solution

To resolve this issue, please follow these steps:

  1. Enable Object Unloading: Set the EnableObjectUnload property to true on your Document instance. This allows the document to partially unload from memory, which can help reduce memory usage.

  2. Free Memory: After saving the document, explicitly call the FreeMemory method on the Document instance to release any unused resources.

  3. Optimize Document: Use the Optimize method before saving the document. This can help reduce the size and potentially the memory footprint.

  4. Update Aspose.PDF: If possible, update to the latest version of Aspose.PDF, as newer releases often include memory management improvements and bug fixes.

Code

Here’s how you can implement these suggestions in your code:

using Aspose.Pdf;

var pdfPath = @"C:\PathToFile\Test.pdf";
var xpsPath = DateTime.Now.Ticks + ".xps";

using (var document = new Document(pdfPath))
{
    document.EnableObjectUnload = true; // Enable object unloading
    document.Optimize(); // Optimize the document
    document.Save(xpsPath, SaveFormat.Xps);
    document.FreeMemory(); // Free memory after saving
}

Next Steps

After implementing these changes, monitor the memory usage during your application’s runtime. If the issue persists, profile your application again to identify any other potential memory leaks. Additionally, if you continue to face challenges, reach out to Aspose support with detailed memory profiling snapshots to assist in diagnosing the issue further.

Please let me know if you need any further assistance!

3

I tried all 4 of those suggestions and none of them improved the memory leak.

4

@tims-1

Can you please share the sample PDF along with some screenshots of the memory consumption for our reference? We will test the scenario in our environment and address it accordingly.

5

Test PDF:
_ZNATWP23011532D_638778828313915644.pdf (11.5 KB)

Initial memory usage 12mb:
image.png (23.3 KB)

After Document constructor 24mb:
image.png (26.3 KB)

After document.Save ~100mb:
image.png (28.1 KB)

A GC occurs after the Document dispose, but memory still ~100mb:
image.png (25.6 KB)

After waiting a while, no more GC’s occur and memory stays ~100mb:
image.png (23.7 KB)

6

@tims-1

We are checking it and will get back to you shortly.

7

@tims-1

Thanks for your patience. We have tested the scenario in our environment with 25.7 version of the API and noticed the issue.

We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.

Issue ID(s): PDFNET-60298

You can obtain Paid Support Services if you need support on a priority basis, along with the direct access to our Paid Support management team.

8

Hi @asad.ali ,

Just wondering if you had made any progress on PDFNET-60298?
Please let me know if you need more information.

Regards,

9

@tims-1

We are afraid that the earlier logged ticket has not been resolved yet. It will be investigated on a first-come, first-served basis as per free support policies. As soon as we have some definite updates about its resolution, we will inform you. We will surely let you know in case we need some information from your side. Please be patient and spare us some time.

We are sorry for the inconvenience.

10

Hi @asad.ali - completely understand.
Are you able to give any indication of where it is sitting in the FIFO queue?

11

@tims-1

The issue is currently in the queue awaiting investigation. The time required for investigation and resolution depends on the number of issues logged ahead of it and the complexity of the matter. Performance and memory-related issues are inherently complex, requiring a thorough analysis and resolution process that may take some time. Rest assured, we will promptly inform you of any updates as they become available.

Thank you for your patience, and we sincerely apologize for any inconvenience caused.