Hard crash (java OOM error) on corrupt input

[GoogleCodeExporter]

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

Attachments:

• NoticiaText-Regular.txt

[GoogleCodeExporter]

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

[GoogleCodeExporter]

"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

• Changed state: New

[GoogleCodeExporter]

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