You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 5, 2023. It is now read-only.
What steps will reproduce the problem?
1. Open corrupt font (for example, in SFD format) with stream-based method such
as loadFonts(InputStream).
What is the expected output? What do you see instead?
Expected result: exception of some sort indicating corrupt font
Actual result:
java.lang.OutOfMemoryError: Java heap space
at com.google.typography.font.sfntly.data.MemoryByteArray.<init>(MemoryByteArray.java:37)
at com.google.typography.font.sfntly.data.WritableFontData.createWritableFontData(WritableFontData.java:43)
at com.google.typography.font.sfntly.Font$Builder.loadTableData(Font.java:951)
at com.google.typography.font.sfntly.Font$Builder.loadFont(Font.java:629)
at com.google.typography.font.sfntly.Font$Builder.getOTFBuilder(Font.java:648)
at com.google.typography.font.sfntly.FontFactory.loadSingleOTFForBuilding(FontFactory.java:181)
at com.google.typography.font.sfntly.FontFactory.loadSingleOTF(FontFactory.java:158)
at com.google.typography.font.sfntly.FontFactory.loadFonts(FontFactory.java:133)
Please use labels and text to provide additional information.
Original issue reported on code.google.com by r...@google.com on 9 Feb 2012 at 7:41
When garbage is fed into a function it seems completely reasonable for the
function to throw an exception. The caller of the function needs to take
responsibility for handling the exception. This seems like a "working as
intended" and I recommend it be closed.
Original comment by bst...@google.com on 10 Feb 2012 at 8:41
"Hard crash" is not an attribute of the OOME. Any Java application or library
can throw that and the there is no way to prevent it without preflighting
_every_ single action which can allocate memory. sfntly could fail with an OOME
on an innocuous seeming HashMap allocation of a half dozen entries. It will
depend on the VM and it's settings and the current state of the environment.
This is a fact of life in Java. Any robust application or server will be
prepared to handle an OOME.
Now, whether sfntly can/should do more validation during the font loading is
another tangential issue. It can be done but it needs to be done in such a way
that it doesn't inhibit performance, doesn't prevent legal sfnt containers from
being loaded, and potentially is optional.
However, even if that does happen there is no way at all to guarantee that
sfntly or any other library including the standard Java library never throws an
OOME unless memory is never allocated.
Original comment by stua...@google.com on 13 Feb 2012 at 11:32
OOME issues will not be fixed as this is a feature of Java. Issue has been
closed. A more appropriately titled issue has been opened to consider some
forms of sfnt container validation. These will never be perfect given the
nature of the problem but maybe some things can be done.
See - http://code.google.com/p/sfntly/issues/detail?id=18
Original comment by stua...@google.com on 13 Feb 2012 at 11:38
Changed state: Invalid
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Original issue reported on code.google.com by
r...@google.com
on 9 Feb 2012 at 7:41Attachments:
The text was updated successfully, but these errors were encountered: