Potential memory leak in printing::PdfMetafileSkia::RenderPage |
|||||||||||||
Issue descriptionOut of Process Heap Profiling is a project that, for a very small set users, records heap allocations and sends back anonymized heap dumps. We've obtained a heap dump that suggests that there's a potential PdfMetafileSkia memory leak. We do not have repro steps. Small allocations [in size or frequency] were pruned from the heap dump before it was uploaded. I've attached the symbolized trace. For instructions on how to use it, see https://chromium.googlesource.com/chromium/src/+/lkcr/docs/memory-infra/heap_profiler.md. In this heap dump, there are 2450 calls to malloc from printing::PdfMetafileCg::RenderPage without corresponding calls to free. These objects take up 642M + 642M (1.2G) of memory.
,
Mar 26 2018
Looks like we aren't releasing a bunch of stuff. For example, I think we need to CGPDFPageRelease after each CGPDFDocumentGetPage. thestig@, does that sound right to you?
,
Mar 28 2018
Uhh, I'll double check the MacOS APIs. Good find.
,
Mar 28 2018
Punting this back since I didn't find anything wrong. Of course I could have easily missed something since I'm not a real Mac developer. I looked over a bunch of example code and they don't release after calling CGPDFDocumentGetPage(). I tried calling CGPDFPageRelease() anyway and that causes a crash in printing_unittests with PdfMetafileCgTest.Pdf. Do we have any idea if the data gets freed eventually after PdfMetafileCg gets destroyed?
,
Mar 28 2018
The easiest way to figure out the leaked objects is to symbolize the missing frames - etienne - can you look into that?
,
Mar 29 2018
I symbolized all the CoreGraphics frames from the top leaks JSON file. All of the leaks appear related to fonts in the PDF. 1) Are there example PDFs that have weird embedded fonts? 2) How is this code path actually triggered? The magnitude and nature of the leak suggest that if we get the right PDF file, and trigger the logic, it should be pretty obvious to see the leak.
,
Mar 29 2018
This code is triggered when printing to a printer or Preview.app. The PDFs are either generated by SkPDF, or are from the PDF Viewer. PDFs can of course embed fonts, so potentially anything can be in there. PDFium has a test corpus and I have a stash somewhere, if you want to try just loading / printing them and see if any of them trigger leaks.
,
Mar 29 2018
Great, I was able to repro this locally without any issue. Repro steps: 1) Open any PDF 2) Open print page [cmd + P] 3) Select Open PDF in Preview Repeat (3). Eventually, close the browser window [but don't quite Chrome]. Note that the memory from (3) is still there. With http://www.pdf995.com/samples/pdf.pdf, I was noticing an ~8MB leak per instance of (3). I used Instruments to take an allocation trace, and saw the same stack that our in-the-wild reporter was showing. Over to thestig@ since we have a local repro. Marking as RB-B for M-68, since printing a large PDF will likely leak a large amount of memory, permanently.
,
Mar 29 2018
I found http://www.openradar.me/28415289 - could this be a bug in MacOS?
,
Mar 30 2018
I haven't gone through the code too far in depth - I suspect that we're incorrectly using CoreGraphics. In the example you post, I suspect that if they made a new CG context and then freed it at the end, that they wouldn't leak resources. Ditto for our code.
,
Mar 30 2018
+ellyjones - this is a reproducible memory leak every time we print a PDF. It might be helpful if someone with macOS experience paired with thestig to investigate further.
,
Apr 6 2018
ellyjones/thestig: Could this be prioritized? A 1.2G leak seems like a significant issue, so please take a look when possible.
,
Apr 6 2018
This may be related to bug 260806 . Can you try applying this CL and see if the leak goes away? https://chromium-review.googlesource.com/c/chromium/src/+/987117 I tried running the browser on Mac with LSAN enabled, but the output was really noisy.
,
Apr 7 2018
I will land my CL when the tree is open. Looking at bug 263359, which caused the bug 260806 fix to be reverted, that was happening in an "ugly hack" for OS X 10.6. That code got removed in r385027, so my CL should be safe. If it is not and we get new crashes, we'll deal with them as they surface.
,
Apr 9 2018
erikchen: Can you check ToT and see if the leak has gone away? If so, mark as a duplicate of bug 260806 .
,
Apr 9 2018
I tried ToT with and without the CL in question - the CL helps a lot, but there's still a leak. With the CL, the amount of leaked memory is down by 1 order of magnitude, from multiple MB per instance to 100s of KBs per instance. To repro: 1) Build Chrome locally 2) Attach Instruments - Allocator 3) Open PDF in print preview many times 4) Close the window. Observe: multiple MBs leaked in CoreAnimation, as well as what appears to be leaked NSWindows. Ah ha! Not sure if this is a leak in MacViews code or Print Preview code. Back over to thestig@, but Elly you may want to take a look at this as well.
,
Apr 9 2018
The leak in comment 17 looks very different from the one in comment 9. I suspect this a MacViews leak, since the print preview code does not leak elsewhere AFAIK.
,
Apr 9 2018
Alright - let's close out this bug since the main issue is fixed. I'll file a new bug with the MacViews bug. |
|||||||||||||
►
Sign in to add a comment |
|||||||||||||
Comment 1 by etienneb@chromium.org
, Mar 23 201887.3 KB
87.3 KB View Download
85.0 KB
85.0 KB View Download
895 KB
895 KB View Download