[jira] [Commented] (PDFBOX-4963) TTF file leakage in font cache

["Maison (Jira)" <ji...@apache.org>]

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

Maison commented on PDFBOX-4963:
--------------------------------

Unfortunately no.
I've tried to reproduce the problem, but no luck up to now (except the duplicate addFont() in case of multi-thread pdf rendering ; but that shouldn't be the main source of problem ?)

Regarding the added finalizers, indeed all articles I could find on internet suggest that it is bad idea. The best alternative seems to be the reference queue, but as you mention the TrueTypeFont would have to somehow publish its internal {{TTFDataStream data;}} it can publish this member as a Closeable however : {{Closeable getInnerCloseable()}} ?



> 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.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org