We are seeing a significant memory leak along with very high CPU usage when generating a thumbnail using Aspose.PDF for .NET. We have tested this with multiple versions and the latest version (23.5.0) has the same issue.
The code we are using to reproduce this problem can be found in your documentation here:
From what we can tell, this issue has been around since version 21.12.0. We have tested 21.12.0, 22.11.0 and 23.5.0 and they all seem to have the same issue. Our .NET SDK version is 6.0.400.
Here is a screenshot of the issue materializing on our Linux cluster after generating a bunch of PDF thumbnails.
Adding some more context here for anyone else who runs into this issue.
We have traced this issue down to Aspose.PDF dependency on System.Drawing.Common which depends on libgdiplus which is littered with bugs and memory leaks on Linux.
Furthermore, it appears that libgdiplus is no longer being maintained. Last update was ~3 years ago.
Finally, the .NET team has decided to abandon support for the System.Drawing.Common library on Linux.
With that said; it looks like there is a new version of Aspose.PDF that does not rely on System.Drawing.Common titled Aspose.PDF.Drawing. This version runs much much smoother on Linux and provides a consistent experience across platforms.
I suggest anyone running into these kinds of issues use the new Aspose.PDF.Drawing library.
It would be nice if this was mentioned somewhere in the documentation. This issue threw us for a loop and we wound up spending the entire day trying to resolve the issue. We also nearly abandoned this library for something else but then I stumbled across another post on the support forum which led me to try this approach.
Before we commit here, is there anything else we should be aware of before moving forward with Aspose.PDF.Drawing?
Yes, we released Aspose.PDF.Drawing for non-Windows environments. It is currently in Beta Version. Once we are sure that it is running without any issues in Linux like environments and in .NET 7.0, we will ultimately make it permanent part of Aspose.PDF for .NET.
Yes, it would work on both Windows and MacOS. We are still in progress of updating it and collecting feedbacks against its experimental versions. As soon as we feel things are going fine and all reported issues are resolved, we will finally merge it into Aspose.PDF.
We are afraid that we don’t have any promising ETA at the moment. However, you can feel free to use it as long as you have Aspose.PDF license. In case we have some updates regarding its merging with Aspose.PDF, we will let you know.
We are suffering extensively from these memory leaks. From your last message, it sounded like you were actively working on a new version of Aspose.PDF that either doesn’t rely on libgdiplus (System.Drawing) or fixes the issues with it.
I didn’t see any evidence that the new fixes have been published yet, so I was asking if the beta version or build of Aspose.PDF with those fixes is available? This statement “We are afraid that we don’t have any promising ETA at the moment. However, you can feel free to use it as long as you have Aspose.PDF license.” suggested to me there might be a way to test the pre-release version.
Is a prerelease version available that addresses this issue?
We’re also seeing issues with Aspose.PDF 23.7.0 and .Net 6 on linux while converting to PDF/A. “System.Drawing.Common is not supported on this platform”
An error occured in async task ManagePayload. document name : <CAKBB7CfXSAxJwn14POdma8MQJ1VqFjQi3JmMueceZ3+JDcSmBQ@mail.gmail.com> : System.Drawing.Common is not supported on this platform.
System.PlatformNotSupportedException: System.Drawing.Common is not supported on this platform.
at System.Drawing.Drawing2D.Matrix..ctor(Single m11, Single m12, Single m21, Single m22, Single dx, Single dy)
at #=zBjGNkwtZmvRiBVY7JdGky5X7poG6$_LCWw==.#=zNflUs9U=(Single #=z2C$cuoM=, Single #=zCc5pLkM=, Single #=z9uLQscI=, Single #=zJzDqMbE=, Single #=zVaJS4HY=, Single #=zqAL8g_A=, #=zo$jDCTST1DMTCyNbWMTxY41TiGIzyxyoLQ== #=zIcfde8E=)
at #=zoZbZ78XusXM_nzRHEWgXZbEII$uJO5J2GinSeIqR_PyD.#=zo7DTOeenaPwV(#=zzQpxVvEtRAcKQf4mPqfkB5IUhcft7SbQFQ== #=zIpbuGsQ=, #=zQ6fM4BzvbRrO81p44wzqxObRBOm7_C5n__oKUgI= #=zQiZ9QPrsD1Fo, #=z4g8GYyWbXdDnqy2VBluKpk8Q6AEcxCpMWw== #=zAyASjyo=, Single #=zWOQn7OJvWyE$, Single #=zNxbhwL8ys9pB, Boolean #=zWAYtb5OdH1sZ0LNDuA==, Int32 #=zZGyTGd_J3_u6uDvYdeiG5Jo=, Boolean #=zzYonwZZEOkAt, Double& #=zC9ZvQ8E=, Double& #=zQPgRNtA=, #=za8ZRH_0Yk2d99N6q91dzRSRuo2z9w9IyJg==& #=ztdeWylc=)
at #=zoZbZ78XusXM_nzRHEWgXZbEII$uJO5J2GinSeIqR_PyD..ctor(#=zr0krvp940Omrbs74ebLaD2SdDwj1 #=z94utm9E=, #=zzQpxVvEtRAcKQf4mPqfkB5IUhcft7SbQFQ== #=zIpbuGsQ=, #=zQ6fM4BzvbRrO81p44wzqxObRBOm7_C5n__oKUgI= #=zQiZ9QPrsD1Fo)
at #=z4hAOjPRvhKgDnzqxMq$dssvdVVUeJkaBXCHKCVY=.#=zUHaF6L7Aiuq2(#=zr0krvp940Omrbs74ebLaD2SdDwj1 #=z94utm9E=, #=zzQpxVvEtRAcKQf4mPqfkB5IUhcft7SbQFQ== #=zIpbuGsQ=, #=zQ6fM4BzvbRrO81p44wzqxObRBOm7_C5n__oKUgI= #=zQiZ9QPrsD1Fo)
at #=zkosqXJ91lGtPyLHtRuqNQuXjrEs4i1r8Y0rdErtSGHZ_.#=z9GkMa7Y=(#=zr0krvp940Omrbs74ebLaD2SdDwj1 #=z94utm9E=, #=zzQpxVvEtRAcKQf4mPqfkB5IUhcft7SbQFQ== #=zIpbuGsQ=, #=zQ6fM4BzvbRrO81p44wzqxObRBOm7_C5n__oKUgI= #=z7RFzjEE=, #=zoZbZ78XusXM_nzRHEWgXZbEII$uJO5J2GinSeIqR_PyD& #=zOVin65g=)
at #=z1DrOFh79Dc8U9Flq8I7GvFzR_R$G.#=zDPfvUN8=(#=zoZbZ78XusXM_nzRHEWgXZbEII$uJO5J2GinSeIqR_PyD& #=zOVin65g=)
at Aspose.Pdf.Devices.ImageDevice.#=zDPfvUN8=(Page #=zIpbuGsQ=)
at Aspose.Pdf.Devices.JpegDevice.Process(Page page, Stream output)
at #=zqF5KpyV8WJCXEVZGGOMqCzS_NXmfNlmlF4vB$uZP1WzYF6SkTtqm8Ts=.#=z4hqIcbCXkirK(Int32 #=zp9pT$Zg=)
at #=zqF5KpyV8WJCXEVZGGOMqCzS_NXmfNlmlF4vB$uZP1WzYF6SkTtqm8Ts=.#=zvUq_Ps6J7jig(Double #=zQaplneo=, Double #=zhiLNSQs=, ImageFilterType #=zU6F58$4=)
at #=zqF5KpyV8WJCXEVZGGOMqCzS_NXmfNlmlF4vB$uZP1WzYF6SkTtqm8Ts=.#=zBacvAusm8zaf(OperatorCollection #=zk_qAn$I=, Resources #=z4AfASA4=, Double #=z8SMm9w0=, Double #=zTB4eiXk=)
at #=zqF5KpyV8WJCXEVZGGOMqCzS_NXmfNlmlF4vB$uZP1WzYF6SkTtqm8Ts=.#=zRHRvz3c=()
at #=zl4T1P_qSB55_1t5QuAoiXrtTydkXJnA2uQiCP8e4HaWkwLMnCIPgQpo=.#=z4RLjpKzzA3vb()
at #=zU4Lb9bfRILmX6H4ZdikCYHCcW3SmNOniYax8NDDyWLwS5VF67TOlXig=.#=zmPe95B8=()
at #=zl4T1P_qSB55_1t5QuAoiXrtTydkXJnA2uQiCP8e4HaWkwLMnCIPgQpo=.#=z1oVXP_o=()
at #=zU4Lb9bfRILmX6H4ZdikCYHCcW3SmNOniYax8NDDyWLwS5VF67TOlXig=.#=z9GkMa7Y=(XmlTextWriter #=zjBlg0EI=, PdfFormat #=zusb73ow=, Document #=z94utm9E=, Boolean #=zmWocEQOBNbKD, ConvertErrorAction #=z83dRYfU=)
at Aspose.Pdf.Document.Convert(Stream outputLogStream, PdfFormat format, ConvertErrorAction action)
It looks like Aspose.Pdf.Devices.JpegDevice.Process still requires System.Drawing.Common. How can we switch to Aspose.PDF.Drawing ?
Yes, we have released Aspose.PDF.Drawing on NuGet Gallery. It does not have dependency on System.Drawing.Common. You can simply remove Aspose.PDF from your project and download/install Aspose.PDF.Drawing through NuGet Package Manager in the Visual Studio. It will support your existing license and will work under .NET 6.
Please also note that it is an experimental release to test whether everything works flawlessly under .NET 6 with it. Once we are sure, it will become part of existing Aspose.PDF API. Please feel free to let us know in case you face any issues with it.
It is nice to hear that you were able to sort the issue out. Please keep using the API and feel free to create a new topic in case you need any kind of assistance.
Are you facing high CPU Usage issue? Can you please confirm if you are using the latest version of the API? And please share your environment details with us as well so that we can share our feedback with you accordingly.
Yes, I am using Aspose.PDF v22.10. My project is moving to the Linux platform. We are having a performance testing. We encountering a significant high cpu and memory leak in the PngDevice which is using for our Thumbnail generation.
Following the suggestions above we have switched to Aspose.PDF.Drawing latest version and the issue is resolved.
My question is when Aspose.PDF.Drawing is going to be merged into Aspose.PDF because we don’t want to use an experimental package in our production
We are working on finalizing the changes in Aspose.Pdf.Drawing and as soon as it is done, we will finally merge it into Aspose.PDF for .NET. There are some components and dependencies that we need to work on and it may take some time. Nevertheless, we will let you know once we have some certain updates in this regard. Please spare us some time.
It’s a real shame that this isn’t yet available for production consumption after all these years. We love the Aspose family of products but this is a real showstopper for anyone who needs to use this in any kind of production linux environment.