Fix font filehandle leak #215
Conversation
Otherwise this may leak file handles. Those file handles should be finalized() sometime in future by the GC, but this may take way to long before all file handles are exhausted. It seems strange that you must subset a font to let its file handle close, but thats the way PDFont is implemented. Usually you always use all the fonts you load into your PDF document. But if you don't use all fonts, the unused fonts leak if they are not subsetted. We also must close all TrueTypeCollections we load. And we don't load fonts provided by file instantly, but rather use a supplier for the font. This more or less also workarounds the file handle leak, as no PDFont is loaded till it is really needed. Before this change the PDFont always has been loaded, even if it is not used. And of course was leaked if the font was not subset.
the font file gets fully loaded into memory.
|
Thanks @rototor Are you saying only fonts loaded but not used leak? If so, perhaps this is a bug in PDFBOX. Anyway, is it possible to use the workaround mentioned in comments at link below, rather than calling subset? Ie. Get a https://stackoverflow.com/questions/35983135/pdfbox-leaves-font-files-open-after-generating-pdf |
|
@danfickle Yes, that should theoretically work too. But it may throw an NPE as close() in TrueTypeFont is not allowed to be called more then once (which is a violation of the close() contract, but ...). To be exact RAFDataStream.close() will crash if it is called twice. Using subset() is a workaround for this problem... Maybe we should merge this ugly workaround and open a upstream ticket to fix close() in fontbox? And as soon as a fix is released we can cleanup this here. |
|
OK, I'll file an issue with PDFBOX and merge this now. Thanks again. |
|
@danfickle did you ever create an issue in PDFBox about this? |
|
No, I failed to get around to it. Should I file one now? By the way, huge thanks for your work on PDFBOX. |
|
No longer needed, see https://issues.apache.org/jira/browse/PDFBOX-4242, please read it and comment if you want. I was just wondering whether we had missed an issue. |
|
Thanks @THausherr I think that discussion covers it. In regard to this project, I was thinking we are only opening unused fonts for their font metrics, so we should probably cache this information between runs and only load the font if actually used in a document. This would be a performance improvement as well as a workaround for this issue. |
…ith our close font workaround. [ci skip] This really needs a release of PDFBOX 2.0.12 for a proper fix.
We've got a file handle leak in production which caused our Tomcat to stop working after some days, and were able to track this down to fonts files which were not closed. After the user generated enough reports the 2048 file descriptors were exhausted and everything stopped working ..
If a font file was registered but not used in the PDF, those font files would leak their file handles.