Hello!
I'm having some strange problems with Aspose.PDF. It seems to deadlock/hang and after few hours it either crashes, with OutOfMemory or tries to write to an output file infinitely.
Overview: I have some code that fetches data from external system, then saves it as data XML file. Then some XSLT tranform is invoked on that file to generate a report XML file structured according to AsposePDF XML API, and finally the latter XML file is fed to BindXML method and a PDF should be generated.
All bits work fine for most reports, but for some input data, the last step (BindXML+Save when using DOM, or BindXML+Close when using DirectWrite) hangs with no apparent reason.
It does not seem to be related to size of the data. I have tested many cases and the final XML file may be 1, 10, 100kb, 1000kb in size and it works fine, yet some 3kb input file may cause a problem.
I managed to observe that this problem occurs mostly when the report contains a Table that contains at least one Image and the Image has some FixHeight or FixWidth option set. I have tested many combinations of image resolutions and FixHeights/Widths and table layouts, but at this this point it seems very random: for some combinations of image input resolutions it always works, for some not, for some resolutions it stops working with specific FixHeight ranges, etc.
I have managed to prepare a series of almost-minimal tests that present the issue. I have attached the code samples and a problematic image and the related XML report template. All of them use default MSTest testing framework, after replacing some paths they should be easy to run directly under VisualStudio.
Please note that the attached XML report file is a TEMPLATE. It contains a placeholder/marker so the test code can easily change the target FixHeight for each testcase. If you'd like to check this template manually, please remember to remove the placeholder and to put there a read FixHeight value.
In the attached code you will find two code files with various tests, please note the difference between them and you will probably want to run them separately, in this order:
1) Simple tests, minimal proof of the problem
That's 4 test cases which show:
- that DOM-method works with some good FixHeight value
- that DirectWrite-method works with some good FixHeight value (same value as above)
- that DOM-method doesn't work for some unlucky FixHeight value
- that DirectWrite-method doesn't work for (the same) unlucky FixHeight value
When the target Height value is lucky
1a,1b) everything works fine, and reports are properly generated both in DOM and DirectWrite way.
When the target Height is unlucky:
1c) the DOM-way starts writing to the output file, creates the file, then internally enters some infitite loop and hangs and eats memory until a OutOfMemory is internally thrown, and then all file handles are closed and we're left with a 0kB PDF file.
1d) The DirectWrite-way starts writing to the output file, creates the file, then internally enters some infinite loop and hangs and constantly writes similar contents to the output file, until we manually kill the task or until it reaches end of disk space. In either way, the resulting PDF is huge and damaged/unreadable.
2) Scanning tests
This series of tests (~1000 actually) that try to run the same specific report as above, but with different FixHeight values (for example from 0px up to 999px), to see how the target size affects the problem. This test suite is mostly automated - it runs each case with different target image size and a watchdog thread guards it so that neither reasonable time nor reasonable filesize are exceeded. Test then reports whether there was some problem or not.
For the provided example XML report template and for given example input image, I observed something results similar to that:
- FixHeights from 0px upto and including 429px are OK and report is generated fine
- FixHeights from 430px and upwards are BAD and Aspose.PDF hangs
Also, when I modified the testcase a little so it was scanning FixWidth instead, it gave different values:
- FixWidths from 0px upto and including 494px are OK and report is generated fine
- FixWidths from 495px and upwards are BAD and Aspose.PDF hangs
But I checked the dimensions and it turns out that when using FixWidth=494px (or 495px), the target Height would be ~429px (or ~430px), so it seems like it's all actually about final Height here, not Width.
Also, I have run similar test for input images of different sizes and with several input images together in one table. Those tests have shown that the threshold value of 430px is not constant. When using an input image(s) of different resultion:
- the library may not hang at all and everything may work fine
- the library may hang only at specific ranges like 300px-600px and work fine outside of it
- the library may hang for files A+B, but would work for A+C, A+D, B+C, B+D, and still fine for combinations like A+B+C, A+B+C+D
Therefore, please do not consider the attached example to be a singular case with these strict causes/constraints. The attached examples are as minimal as I was able to narrow the problem, but the problem itself seems to be larger. It seems like the library is unable to properly calculate table's layout due to some (maybe rounding?) problems with image scaling. I don't see why would it eat up resources/write infinite file though. But it does.
I think it's some problem with Tables and calculating layout, because I have tried changing/removing paddings/margins/columnwidths from the Table, and the Height threshold were changing a bit and for some combinations even sometimes the problem disappeared (but was back when I changed the source image).
I/We are currently working with Aspose.PDF v9.6 and we noticed this problem in this version, and I researched the problem and prepared testcases for this version.
However, I have also tried Aspose.PDF v10.3 (the one which currently available on NuGet) and sadly I have to say that the problem still occurs. The v10.3 presents the same behavior as 9.6 in this testcases - still hangs and OOMs or stucks at infinite-write, depending on the DOM/DirectWrite choice.
Please advise on this case.
regards,
t.p.
PS. Oh, and removing Tables from the report doesn't seem to fully solve the problem, I have tried that, it somewhat helped, but it generated some other problems. Anyways, having a scaled image inside a table is quite .. basic thing. We'd like to be able to put an image into some grid or table.