[prev in list] [next in list] [prev in thread] [next in thread] 

List:       poi-dev
Subject:    DO NOT REPLY [Bug 9448] New:  -
From:       bugzilla () apache ! org
Date:       2002-05-27 19:44:18
[Download RAW message or body]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9448>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9448

HSSF fails to properly handle extended strings over continuations

           Summary: HSSF fails to properly handle extended strings over
                    continuations
           Product: POI
           Version: 1.5.1
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Critical
          Priority: Other
         Component: HSSF
        AssignedTo: poi-dev@jakarta.apache.org
        ReportedBy: daniel@cheeseplant.org


Reading an excel produced spreadsheet crashes with a NegativeArraySizeException
to be thrown in processString.

I've done some extensive delving to try and find the cause of this problem and
hopefully fix it, what it boils down to is that there's a few incorrect
assumptions made in bits of SSTRecord (specifically within  manufactureStrings
and processContinueRecord) which fail if one has a string with  extended
information that doesn't fit completely in the middle of a record (i.e. one
which requires continue records).

I have a nasty suspicion that this is a design issue which would require
re-working the parser so that instead of trying to build an incomplete string
up, it'll have to assemble an 'accumulated record' before string parsing, until
the whole string and its other data can be fished out (or appropriately ignored).

I can if necessary provide a spreadsheet which exhibits this problem, though
it's pretty large.  It may well be that a simple example is enough, though:

Part way through a record there's a string which has a char_count of 44.
This is a wide string, so its initial byte count is 91, and it also has the
extended flag set, so that the total size expands up to 26719 bytes [Which is
obviously too big to fit in a single buffer].

When manufactureStrings gets to this, it realizes it's going to cross records,
but the subsequent 'partial string' logic completely fails to take into account
both the additional length field BEFORE the string, and that some of the final
size might not actually be part of the character data, so it ends up vastly
overestimating how many characters the string would be.

I can't see any way of fixing this without re-writing the continuation handling
as described above (and that's a little too major of a change for me to attack
at this moment, especially since I only downloaded HSSF yesterday! 8-))

--
To unsubscribe, e-mail:   <mailto:poi-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:poi-dev-help@jakarta.apache.org>

[prev in list] [next in list] [prev in thread] [next in thread]