Maison created PDFBOX-4963:
------------------------------
Summary: 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
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: [email protected]
For additional commands, e-mail: [email protected]
