[
https://issues.apache.org/jira/browse/DERBY-3739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-3739:
--------------------------------------
Attachment: d3739-skip.stat
d3739-skip.diff
skip() also had a problem when the count argument was negative. According to
the javadoc for InputStream.skip(), the return value should be 0 in that case
and no bytes should be skipped, but ArrayInputStream's implementation would
decrease the position pointer and return the negative number. The attached
patch fixes both the overflow and the problem with a negative argument.
skipBytes() has the same problems, so I made it forward calls to skip() in
order to fix the problem there as well.
I didn't find any way to trigger the bug from user code since none of the
streams that are returned to the users are built on top of ArrayInputStream, as
far as I could see. Still, I think it should follow the contract of InputStream
so that it doesn't give us any unpleasant surprises if we start using
ArrayInputStream in other ways than we currently do. Since I couldn't find a
way to test this through JDBC or SQL, I created ArrayInputStreamTest which
tests the class directly.
I also noticed that read(byte[],int,int) and readFully(byte[],int,int) have
similar issues. Will fix those in a separate patch.
suites.All and derbyall ran cleanly with the patch.
> Calls to ArrayInputStream.skip() may overflow and have unexpected results
> -------------------------------------------------------------------------
>
> Key: DERBY-3739
> URL: https://issues.apache.org/jira/browse/DERBY-3739
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.5.0.0
> Reporter: Knut Anders Hatlen
> Assignee: Knut Anders Hatlen
> Priority: Minor
> Attachments: d3739-skip.diff, d3739-skip.stat
>
>
> If ArrayInputStream.skip() is called with a large value (like Long.MAX_VALUE)
> an internal calculation may overflow and cause unexpected results.
> It's the line which says
> if ((position + count) > end) {
> that can overflow. If count (a long) is so big that position + count doesn't
> fit in a long, the condition will evaluate to false although it should have
> evaluated to true. Changing the condition to (count > end - position) will
> fix the problem. Alternatively, we could simplify the entire method body to:
> count = Math.min(count, end - position);
> position += count;
> return count;
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.