IronPDF 导致内存泄漏

Question

I am using IronPDF to generate PDF documents. My program is a web app hosted on IIS that uses ChromePdfRenderer to render PDF using an HTML string, and it sequentially generates a bunch of documents. I noticed over time, total memory used by the process increases and ultimately crashes. Further investigation showed the unmanaged memory keeps increasing as it generates PDFs.

I wrote a sample console app to replicate this

public class PdfBenchmark{

    private static readonly ChromePdfRenderOptions ChromePdfRenderOptions = new ChromePdfRenderOptions
    {
        PaperSize = IronPdf.Rendering.PdfPaperSize.Letter,
        CssMediaType = IronPdf.Rendering.PdfCssMediaType.Screen,
        PrintHtmlBackgrounds = true,
        FitToPaper = true,

        EnableJavaScript = true,
        RenderDelay = 200,
        Timeout = 60
    };

    public async Task<Stream> SimplePdf()
    {            
        var renderer = new IronPdf.ChromePdfRenderer()
        {
            RenderingOptions = ChromePdfRenderOptions
        };

        renderer.RenderingOptions.HtmlHeader.MaxHeight = 25;
        renderer.RenderingOptions.HtmlHeader.DrawDividerLine = false;
        renderer.RenderingOptions.HtmlHeader.HtmlFragment = HeaderHTML;

        renderer.RenderingOptions.HtmlFooter.MaxHeight = 12;
        renderer.RenderingOptions.HtmlFooter.DrawDividerLine = true;
        renderer.RenderingOptions.HtmlFooter.HtmlFragment = FooterHTML;


        using (var x = await renderer.RenderHtmlAsPdfAsync("<h1>Html with CSS and Images and js</h1>"))
        {
            return x.Stream;
        }                
    }


    public const string FooterHTML = @"<div class='container-fluid'>some html</div>";

    public const string HeaderHTML = @"<div class='container'>
                                <div class='row header d-flex justify-content-between'>
                                    <div class='col-md-1 logo'>
                                    </div>
                                    <div class='col text-end right'>
                                        <div>>some HTML content</div>
                                    </div>
                                </div>
                            </div>";

    }
}

static async Task Main(string[] args)
{            
    var x = new PdfBenchmark();
    for (int i = 0; i < 200; i++)
    {
        using var stream = await x.SimplePdf();
        //Do whatever I want here...
        Console.WriteLine($"Created doc#: {i}");
    }
}

the larger the HTML, the quicker the memory usage grows. Here's the memory profiler snapshot.

You can see how unmanaged memory grew fast, but wasn't released after about 100 iterations. I've reproduced this on .NET Core 3.1 and .NET Framework.

Has anyone else had this issue and how did you resolve this? IronPDF support has been useless so far.

Answer 1

IronPDF acknowledged there was a memory leak in their Chrome renderer and they've fixed the issue. Fix is available from version 2021.11.4257 onwards.

Answer 2

The memory leak is resolved in IronPdf update 2021.11.4257, released 2021-11-15. https://www.nuget.org/packages/IronPdf/2021.11.4257

• Fixes memory leaks (see attached images below)
• Adds Installation.ChromeBrowserLimit
• Adds AWS support. Full Docker setup tutorial here - https://iron.helpscoutdocs.com/article/115-aws-lambda-amazon-linux-2 (this does not yet include support for AWS "Layers")
• Updated exception messages, to allow developers to diagnose more issues
• Several minor bug fixes

What will be in our next update? (known issues):

Applying headers and footers to a document with a page count greater than 30 currently causes an issue, so to successfully apply headers and footers to documents with a page count greater than 30, you must add IronPdf.Installation.ChromeBrowserLimit = 50; where "50" is greater than the expected page count of your large document.

How long was there a memory leak?

Around November 1st in IronPdf 2021.11.4183

Why did this occur?

Our Chrome renderer is relatively new unmanaged propriety code. A recent update caused a memory leak which was not captured due to inadequate extended performance profiling.

How will this be prevented in the future?

We have implemented extended performance profiling for our "continuous integration" process to ensure that both our managed and unmanaged code performance is up-to-par before releasing IronPdf to the public.

2 files