Summary: | When attached testing code is executed against the attached document, it generates the exception here under. | ||
---|---|---|---|
Product: | POI | Reporter: | Philippe Dubois <philippe.dubois> |
Component: | HPSF | Assignee: | POI Developers List <dev> |
Status: | RESOLVED FIXED | ||
Severity: | critical | CC: | alan.davis.apache |
Priority: | P2 | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
Attachments: |
Java test to generate exception
Document used to generate the exception Proposed patch |
Description
Philippe Dubois
2012-12-03 09:49:10 UTC
Created attachment 29667 [details]
Document used to generate the exception
Document used to generate the exception. Generate using ASPOSE
Created attachment 29668 [details]
Proposed patch
The attached UnicodeString.java.patch allows POI to recover from the type of error found in the file generated by http://www.aspose.com The file specifies an offset to a UnicodeString parameter, which is out by 2 bytes. The real offset starts on a 4 byte boundary. The patch works by checking the offsets provided to make sure the UnicodeString appears valid. The original code checked the UnicodeString ends in a NULL character, AFTER it had copied the string into a new byte[]. The patch does this check BEFORE the copy avoiding the creation of a very large byte[] followed by an ArrayIndexOutOfBoundsException. As a result it is able to also check if changing the offset to a 4 byte boundary would solve the problem. It needs some work. At least one unit test started to fail after I applied your patch: org.apache.poi.hpsf.IllegalPropertySetDataException: UnicodeString started at offset #68 is not NULL-terminated at org.apache.poi.hpsf.UnicodeString.<init>(UnicodeString.java:48) at org.apache.poi.hpsf.TypedPropertyValue.readValue(TypedPropertyValue.java:162) at org.apache.poi.hpsf.VariantSupport.read(VariantSupport.java:166) at org.apache.poi.hpsf.Property.<init>(Property.java:164) at org.apache.poi.hpsf.Section.<init>(Section.java:277) at org.apache.poi.hpsf.PropertySet.init(PropertySet.java:451) at org.apache.poi.hpsf.PropertySet.<init>(PropertySet.java:246) at org.apache.poi.hpsf.PropertySetFactory.create(PropertySetFactory.java:59) at org.apache.poi.POIDocument.getPropertySet(POIDocument.java:165) at org.apache.poi.POIDocument.readProperties(POIDocument.java:126) at org.apache.poi.POIDocument.getSummaryInformation(POIDocument.java:93) at org.apache.poi.TestPOIDocumentMain.testCreateNewPropertiesOnExistingFile(TestPOIDocumentMain.java:161) Please run the "test" ant target and ensure it completes OK. Yegor Alan and/or Philippe - any luck on a version of the patch that doesn't break the unit tests? I've had a go at fixing this in r1496675. All the POI tests pass with my fix, and the code is hopefully a little easier to follow than in the original patch. I've added a unit test based on the sample file supplied, which shows we can now read the metadata without error This has just missed out on being in poi 3.10 beta 1 though, so I guess we're stuck with a patched copy of POI in Alfresco for a little bit longer :/ If it helps, I can raise a new Alfresco support ticket, and/or buy a round in the Bear...! |