Mailing-List: contact poi-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "POI Developers List" <poi-dev@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Date: Thu, 23 Sep 2004 23:46:50 -0400
From: Michael Zalewski <zalewski@optonline.net>
Subject: RE: Bug + fix
In-reply-to: <C1ECA5ECAA06A64D88D955E9E152680D32A5C2@SNOWBALL2.asc.com.au>
To: POI Developers List <poi-dev@jakarta.apache.org>
Message-id: <NFBBJLHLDKIEPKFLMKJDKEGLCKAA.zalewski@optonline.net>
MIME-version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Importance: Normal

I can vouch for this fix. In fact, at least four different users (including
myself) have submitted almost exactly the same patch. Yet the bug remains in
the source code.

The problem is the ftLbsData subrecord (type 0x13), which is interpreted by
POI to have a very long length. The ftLbsData record is present whenever you
have a dropdown in the worksheet, such as through user forms, or with data
validation turned on. The record length on the ftLbsData record is always a
value like 0x1fee, which I cannot interpret. 0x1fee may be some kind of
magic number, or it might be some kind of garbage if ftLbsData always has a
fixed size. Every sheet I have looked at seems to have a 16 byte ftLbsData
sub-record. I would very much like to see a sample spreadsheet where the
ftLbsData subrecord reports some length other than 0x1fee.

Take a look at the patch I submitted on
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27929 (oddly enough, its
marked as fixed now, but the code does not seem to be in CVS). I even
supplied a Junit testcase. In my patch, I did this:

+        short adjustedSize = size;
+        if( size < 0) {
+           adjustedSize = 0;
+        } else if( offset + size > data.length) {
+           adjustedSize = (short) (data.length - offset);
+           if( adjustedSize > 4) {
+              adjustedSize -= 4;
+           }
+        }

This code is a little more thorough than Manjuka's proposed patch - it
handles negative lengths which might be found in the UnkonwnRecord. It also
attempts to not eat the last 4 bytes of the OBJ record. That should be an
ftEnd subrecord, and the ftEnd record always seems to be present, even when
there is a ftLbsData subrecord with an incorrect length. An ftEnd record is
always 4 bytes of 0x00, so the patch I provide tries to leave the last 4
bytes out of the UnkownRecord.


-----Original Message-----
From: Height, Jason [mailto:jheight@subcorp.com.au]
Sent: Thursday, September 23, 2004 9:38 PM
To: POI Developers List
Subject: RE: Bug + fix

Manjuka,

Actually your fix doesn't look quite "right". I have usually found that
these kind of problems are caused by some other records up stream
reporting their size incorrectly. And therefore the downstream records
getting all mixed up by that byte offset.

If possible would you be able to create a bugzilla report and attach an
example spreadsheet and the code to reproduce the bug.

Maybe you could have a further look if possible.

Jason

-----Original Message-----
From: Manjuka Soysa [mailto:Manjuka.Soysa@colesmyer.com.au]
Sent: Friday, 24 September 2004 10:50 AM
To: 'poi-dev@jakarta.apache.org'
Subject: Bug + fix


Hi,
I had a problem parsing some spreadsheets that had filters at the top
(combo-box type dropdowns).
Calling HSSFWorkbook constructor was throwing an array out of bounds
exception.
I traced the problem to UnknownRecord constructor. I have attached the
fix.
Old code:
    public UnknownRecord( short id, short size, byte[] data, int offset
)
    {
        sid     = id;
        thedata = new byte[size];

        System.arraycopy(data, offset, thedata, 0, size);
    }

Fix:
    public UnknownRecord( short id, short size, byte[] data, int offset
)
    {
        sid     = id;
        thedata = new byte[size];

        int copyLength = Math.min(size, data.length - offset);

        System.arraycopy(data, offset, thedata, 0, copyLength);
    }

cheers,
Manjuka

This email and any attachments may contain privileged and confidential
information and are intended for the named addressee only. If you have
received this e-mail in error, please notify the sender and delete this
e-mail immediately. Any confidentiality, privilege or copyright is not
waived or lost because this e-mail has been sent to you in error. It is
your responsibility to check this e-mail and any attachments for
viruses.  No warranty is made that this material is free from computer
virus or any other defect or error.  Any loss/damage incurred by using
this material is not the sender's responsibility.  The sender's entire
liability will be limited to resupplying the material.

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


----------------------------------------------------------------------------
----------------------------------------
This e-mail (including attachments) is confidential information of
Australian Submarine Corporation Pty Limited (ASC).  It may also be legally
privileged.  Unauthorised use and disclosure is prohibited.  ASC is not
taken to have waived confidentiality or privilege if this e-mail was sent to
you in error. If you have received it in error, please notify the sender
promptly.  While ASC takes steps to identify and eliminate viruses, it
cannot confirm that this e-mail is free from them.  You should scan this
e-mail for viruses before it is used.  The statements in this e-mail are
those of the sender only, unless specifically stated to be those of ASC by
someone with authority to do so.


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


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