Bug 40008 - Support Excel Ptg 0x1a (sheet)
Summary: Support Excel Ptg 0x1a (sheet)
Status: RESOLVED FIXED
Alias: None
Product: POI
Classification: Unclassified
Component: HSSF (show other bugs)
Version: 3.2-FINAL
Hardware: Other other
: P2 normal (vote)
Target Milestone: ---
Assignee: POI Developers List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-07-11 01:51 UTC by Trejkaz (pen name)
Modified: 2009-11-04 19:00 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Trejkaz (pen name) 2006-07-11 01:51:11 UTC
Encountering Ptg 0x1a currently makes POI throw an exception, failing to load
the entire document.
Comment 1 Jason Height 2006-07-26 11:21:07 UTC
Interesting, this ptd is listed in the developers guide as being deleted and no
longer used. Was the file that caused this error generated using excel?
Comment 2 Trejkaz (pen name) 2006-07-26 13:15:05 UTC
Supposedly it was.  I don't have my hands on the file itself, the error came 
from a customer site.  Could it be that it came from an earlier version of 
Excel?
Comment 3 Yegor Kozlov 2008-05-17 06:24:52 UTC
Is the problem still reproducible with poi-3.1-beta1? 

Yegor
Comment 4 Trejkaz (pen name) 2009-11-01 14:57:47 UTC
I am willing to assume that the problem in its original form no longer occurs, because:

			case AttrPtg.sid:                
			case 0x1a:        return new AttrPtg(in); // 0x19

Though I'm not sure why this would work, I don't have source data to prove otherwise, so I'm assuming this was fixed whenever that line of code was added.

I can't set the version it was fixed in so I'm setting it to NEW so someone with permission can.
Comment 5 Josh Micich 2009-11-04 19:00:24 UTC
From the documentation, Ptg 0x1A seems to be only used until BIFF4, where it was known as "tSheet".  It seems most likely that the original source of this error was a problem elsewhere in the Ptg deserialization logic that caused an mis-aligned read.

I made sure that no example files on hand disagree with this conclusion.  The code you mentioned (which apparent handles Ptg 0x1A) has been removed in svn r832975 (it was originally added in svn r615859 as part of the fix for bug 42618).


Note - problems like this are harder to reproduce after svn r709235.  In that change, formulas no longer get eagerly converted to Ptg arrays.  Now this only happens when the calling Cell.getCellFormula() and during formula evaluation.  So if the original problem were still present, it may not surface until you access the formula in the offending cell.  For enhanced testing, the following modification can be made to Formula.java (forcing every formula to be deserialized to Ptg arrays):  


--- src/java/org/apache/poi/ss/formula/Formula.java     (revision 832596)
+++ src/java/org/apache/poi/ss/formula/Formula.java     (working copy)
@@ -77,7 +77,9 @@
        public static Formula read(int encodedTokenLen, LittleEndianInput in, int totalEncodedLen) {

                byte[] byteEncoding = new byte[totalEncodedLen];
                in.readFully(byteEncoding);
-               return new Formula(byteEncoding, encodedTokenLen);
+               Formula result = new Formula(byteEncoding, encodedTokenLen);
+               result.getTokens();
+               return result;
        }


I ran all the junits with this additional change in place, to make sure that Ptg 0x1a is not referenced in any existing sample file.  (Incidentally there still seems to be examples of Ptg 0x00)