Aspose.PSD 24.7.0 Memory leaking issue

Aspose.PSD Product Family
1

I am running into issues with Aspose.PSD leaving a large amount of allocated memory when the portion of my code that actually uses Aspose finishes. I am not sure why it is not being cleaned up by GC for many reasons including the facts that the class that utilizes Aspose is disposed of and the thread that the class and Aspose runs on gets terminated before a GC collection is called. The following image is a screenshot of a diagnostic session with the program. At about 3:34 is when the thread Aspose is running on is terminated and where the memory usage should go down but doesn’t. In the Call Tree, Aspose.PSD.Image.Save takes the most memory by far with another large memory hog being a function (not in the screenshot) that analyzes the int[] returned by Aspose.PSD.RasterImage.LoadArgb32Pixels.

image.png (109.2 KB)

I have tried various solutions to this issue, but none have shown any progress. The program is intended to be used to export individual layers as .pngs if that helps at all. I have attached the diagnostic file here: Memory Leak Issue - Google Drive

Edit: I added an example .psd file to the above Google Drive. It is a version of the .psd file the screenshot is taken from with all the rasterized image layers being turned to all white or all black. It still has the memory issue though.

2

@Skeletax
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): PSDNET-2154

Could you please additionally provide minimum required code to reproduce the issue.

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.

3

@Dmitriy.Sorokin I have uploaded my code to the Google Drive in the initial post, quoted below as well.

4

I’ve update Task with your code sample. Thank you, you will be notified when the issue will be fixed, or if there can be any workaround.