Saving PDF document to memory stream locks up computer, uses up all memory

Aspose.PDF Product Family
1

We are having an issue converting a text note to a PDF using Aspose PDF 23.1.1 for .net, but it doesn’t happen often - maybe one in 10 or 20 conversions.

A pdf is built, and written to a memory stream. Every dozen or so times, the code never returns from the Save, the CPU spikes and eventually Aspose uses up all the memory on the server.

During my investigation, I saved the PDF as an XML file, and then read it back in again to see if that might change the behaviour. It did not, but I could reproduce the issue using the XML file that was not converting.

I wrote a simple app to read in the XML document as a PDF, and save it to a memory stream.

My code to do this is,

        License license = new License();
        license.SetLicense("Aspose.PDF.NET.lic");

        Document doc = new Document();
        doc.BindXml("C:\\temp\\doc.xml");

        MemoryStream ms = new MemoryStream();
        doc.Save(ms);
        return;

I’ve attached the XML document I’ve been using.

doc.7z (1.4 KB)

3

@davidgriffiths
Thank you for picking up the file with which the error occurs and providing the code. The error has been reproduced - the task will be set. As a workaround, I can note that if the fractional part of the number 49 is removed in two places in this file, then an exception does not occur.
fraction.png (6.3 KB)

5

@davidgriffiths
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-53700

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.

6

Great - thanks. Funny that the MarginInfo object fields left, right, header, footer are doubles, but doubles crash the generation. Will see if I can cast to an int.

7

@davidgriffiths
I will let you know as soon as ticket information is available.

8

A quick update. I changed our code to set the margins to an int, rather than a double. It still hangs. I looked through the XML file that recreates the issue - there are no numbers that are doubles.

I’ve attached the new file that has the same issue.

doc.7z (1.4 KB)

9

Some additional info. I removed all the text from the TextState element, and it did not hang.

I started to paste it back in, line by line, until it failed again. If I Ieave 1806 text characters in the element, it’s fine. If I add one additional character (a space), it fails. If I repeat the letter “a” 2000 times, it’s fine.

So it’s some combination of the text and the length (over 1806). I’ve attached two XML files - one that works, one that does not, clearly labeled. The only difference between the two is an extra space at the end of the text in the TextState element.

David

Temp.7z (1.5 KB)

10

@davidgriffiths
Thank you very much for the additional information on this matter. I will add it to the ticket and I think it will help to find the error faster.

11

Unfort, we’re getting a lot of flack from a customer about the locking up of the PDF generation - the library eventually consumes all the memory on the server and they are unable to print documentation for patients.

If we were to purchase support, what sort of turn-around would we see?

12

@davidgriffiths
Your task’s priority would be raised.
I looked at the current status of the PDFNET-53700 task - it is not even assigned to anyone at the moment.
(apparently there are quite a lot of tasks with high priority).