[ 
https://issues.apache.org/jira/browse/PDFBOX-4963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622961#comment-17622961
 ] 

Kenichi Suzuki edited comment on PDFBOX-4963 at 10/24/22 6:24 AM:
------------------------------------------------------------------

Hey guys.
Is there a solution in this case? Please let me know if you have a solution, 
even if it is tentative. An actual example would be very helpful. Also, has 
anyone tried this with other versions? (e.g., version 3)
Thank you in advance.


was (Author: JIRAUSER297386):
Hey guys.
Is there a solution in this case?
Please let me know if you have a solution, even if it is tentative.
An actual example would be very helpful.
Also, has anyone tried this with other versions? (e.g., version
3)
Thank you in advance.

> TTF file leakage in font cache
> ------------------------------
>
>                 Key: PDFBOX-4963
>                 URL: https://issues.apache.org/jira/browse/PDFBOX-4963
>             Project: PDFBox
>          Issue Type: Bug
>          Components: PDModel
>    Affects Versions: 2.0.21
>            Reporter: Maison
>            Priority: Major
>
> We observe many TTF opened files in our production server, which result in 
> exhausting file descriptors.
> We have checked and rechecked that every PDDocument is properly closed (try 
> with resource everywhere).
> By looking at pdfbox source code, I suspect 2 problems in FontCache and in 
> FileSystemFontProvider
> 1 - FontCache
> In FontCache, a map keeps SoftReference<FontBoxFont> as values.
> IIUC for TTF fonts, the values are instances of 
> org.apache.fontbox.ttf.TrueTypeFont. Such instances have a TTFDataStream 
> member, which is RAFDataStream (so there is an opened file).
> Problem is that if the soft reference is cleared by GC, we can suppose the 
> TrueTypeFont objects are GCed (is that guaranteed?) ; but what about the 
> RAFDataStream sub-object ? There is no RAFDataStream.close() in TrueTypeFont 
> finalizer
> 2 - FileSystemFontProvider
> There seems to be a TOCTOU-like race condition when a font is needed. Code 
> looks like below (simplified) :
>      @Override
>       public FontBoxFont getFont()
>        {
>           FontBoxFont cached = parent.cache.getFont(this);
>           if (cached != null) {
>                return cached;
>           }
>           FontBoxFont font = ... // instantiate font
>           parent.cache.addFont(this, font);  // <--- not thread safe ?
>           return font;
>     }
> The font, if not in cache, is instantiated and added into cache. But two 
> threads can do that at the same time, and the last addFont() wins. So the 
> first SoftReference<FontBoxFont> object is now eligible to GC; but the 
> FontBoxFont has not been closed.
> This problem is probably less frequent.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to