[
https://issues.apache.org/jira/browse/FOP-3193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17909069#comment-17909069
]
Julian Müller commented on FOP-3193:
------------------------------------
[~jgoncalves] It wasn't my own machine, but a user's Unix system, so I didn't
have access to that machine and don't know the specific setup of the
directories. The call stack was telling, though:
{code}
java.lang.Thread.State: RUNNABLE
at
java.io.UnixFileSystem.getBooleanAttributes0(mailto:java.base@11.0.22/Native
Method)
at
java.io.UnixFileSystem.getBooleanAttributes(mailto:java.base@11.0.22/UnixFileSystem.java:253)
at java.io.File.isDirectory(mailto:java.base@11.0.22/File.java:861)
at
org.apache.commons.io.filefilter.DirectoryFileFilter.accept(SourceFile:96)
at org.apache.commons.io.filefilter.AndFileFilter.accept(SourceFile:119)
at org.apache.commons.io.filefilter.OrFileFilter.accept(SourceFile:111)
at java.io.File.listFiles(mailto:java.base@11.0.22/File.java:1342)
at org.apache.commons.io.DirectoryWalker.walk(SourceFile:362)
at org.apache.commons.io.DirectoryWalker.walk(SourceFile:369)
at org.apache.commons.io.DirectoryWalker.walk(SourceFile:369)
[...]
at org.apache.commons.io.DirectoryWalker.walk(SourceFile:369)
at org.apache.fop.fonts.autodetect.FontFileFinder.find(SourceFile:175)
at
org.apache.fop.fonts.FontDetectorFactory$DefaultFontDetector.detect(SourceFile:96)
[...]
{code}
As for how to create this, my guess would be symbolic links or a directory
mounted into itself somehow. But I didn't inquire further.
We implemented a workaround that essentially just ended up passing a depth
limit different from -1 to FontFileFinder (I _think_ we used 10). Afterwards, I
confirmed with the user that this made the issue go away.
> Font auto-detection crashes on systems with internally recursive font
> directories
> ---------------------------------------------------------------------------------
>
> Key: FOP-3193
> URL: https://issues.apache.org/jira/browse/FOP-3193
> Project: FOP
> Issue Type: Bug
> Affects Versions: 2.9
> Reporter: Julian Müller
> Assignee: Joao Goncalves
> Priority: Major
>
> A user reported to us that our application crashes when exporting to PDF. We
> traced it down to the fact that FOP's FontFileFinder was infinitely recursing
> over font directories on that user's system, i.e., a font directory on this
> user's system contained itself.
> This potential infinite recursion is currently hardcoded in
> FontDetectorFactory.DefaultFontFactory.detect():
> {code:java}
> // search in font base if it is defined and
> // is a directory but don't recurse
> FontFileFinder fontFileFinder = new FontFileFinder(eventListener);
> [...]
> List<URL> systemFontList;
> systemFontList = fontFileFinder.find();
> {code}
> Note that the leading comment at the top is not true: The font file finder
> potentially recurses to an arbitrary depth when this constructor is called.
> I think FOP should set a reasonable limit on the recursion depth when
> auto-detecting fonts to avoid crashing on systems with recursive directory
> structures, or it might even be preferable to make the maximum recursion
> depth in the font auto-detect feature configurable for users of FOP. As
> things stand, it is hard to defend against this issue because FOP makes it
> difficult to avoid the infinite recursion when the font auto-detection
> feature is enabled (e.g., PDFTranscoder hardcodes the usage of
> PDFDocumentGraphics2DConfigurator, which hardcodes the usage of the default
> font detector, which hardcodes the infinite recursion).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
