[ 
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.

Reply via email to