0

I've recently ported an ASP.NET web project to ASP.NET Core (net5.0).

In this project static HTML files are converted to PDF files and stored in a database. We are using EvoPDF for this and everything was fine before we switched to net5.0.

Now from time to time we'll get this error:

System.Exception: Could not create image object. Out of memory.
         at EvoPdf.HtmlToImageConverter.?(String A_0, String A_1, String A_2, ?& A_3, Hashtable& A_4)
         at EvoPdf.HtmlToPdfConverter.?(String A_0, String A_1, String A_2, String A_3, Boolean A_4)
         at EvoPdf.HtmlToPdfConverter.?(Stream A_0, String A_1, String A_2, String A_3, String A_4, Boolean A_5)
         at EvoPdf.HtmlToPdfConverter.ConvertHtmlToStream(String htmlString, String baseUrl, String internalLinksBaseUrl, Stream outPdfStream)
         at EvoPdf.HtmlToPdfConverter.ConvertHtmlToStream(String htmlString, String baseUrl, Stream outPdfStream)

The project was built as 64 bit binary. It runs on an IIS and we checked that it really runs in a 64 bit pool. The application itself uses roughly 200 - 400 MB memory and has lots of free memory on the machine. So this shouldn't be a problem.

Our html files aren't really fancy and it happens with small pages as well as on big pages.


var evo = new EvoPdf.HtmlToPdfConverter();
//...
using (var stream = new MemoryStream())
{
    string baseUrl = "";
    evo.ConvertHtmlToStream(html, baseUrl, stream);
    return stream.ToArray();
}

The said domain logic classes are inserted with transient lifetime and all dependencies (pdf creation included) as well. We checked captive dependencies, but found none.

Right know we don't know what to do, because the exception happens just occasionally and we cannot reproduce this on the development machines.

Any ideas on what to do?

MiVoth
  • 972
  • 6
  • 16
  • 1
    Are you making sure those arrays you produce are eligible for collection as soon as they can be? If the PDFs are over 85 kb, you are severely stressing the Large Object Heap, and making the Garbage Collector busy doing Gen2 collections. Use Performance Monitor (perfmon) and the _.NET Memory Counters_ to see what's going on. – Flydog57 Oct 18 '21 at 21:36
  • If this library has anything to do with the GDI, your physical memory may not be the issue, and could likely be a large nasty bug in the actual product caused by incorrect usage of GDI objects – TheGeneral Oct 18 '21 at 21:40
  • @Flydog57 Well the files are PDFs so: yes they easily are over 85kb. There is a ```ConvertHtmlFileToFile``` method in EvoPDF. I haven'nt used it, because i don't like writing on filesystem in a web project. @TheGeneral I've tought about this as well. But why was it working on the framework project? – MiVoth Oct 19 '21 at 04:44
  • 1
    When I was at Microsoft, I had two customers who had EOM issues with PDF generation inside a web app (granted, they were both in the v1.1 and v2.0 time frame). Doing it in managed memory plays hell with the LOH. The GC can't keep up with all those Gen2 collections. The solution was to convert it to PDF outside managed code, writing to a temp folder, and then using (IIRC), `Response.TransmitFile` to send it directly to the client from the file system. – Flydog57 Oct 19 '21 at 05:19
  • Ok, that doesn't sound good. We usually don't serve the PDF files to the user. They a generated to be stored in the database. Every change has to be tracked and an before-after-pdf is saved. Right know I'm thinking about a complete rollback to framework 4.8 as everything was working fine there... – MiVoth Oct 19 '21 at 06:55
  • Take a look at what's going on with PerfMon, maybe you'll see something – Flydog57 Oct 19 '21 at 11:33

0 Answers0