[
https://issues.apache.org/jira/browse/DERBY-4519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12802307#action_12802307
]
Knut Anders Hatlen commented on DERBY-4519:
-------------------------------------------
Another problem with this code is that it uses InputStream.available() to
decide the size of the read buffer. If available() returns 0 (which it is
allowed to) an empty read buffer is used, and this will also lead to an
infinite loop, I think.
The patch looks like an improvement, though. Minor nit: Calling the
read(byte[]) method that takes no offset/length arguments would be equivalent
to read(bufData,0,bufferLen) and slightly simpler.
> Infinite loop in StreamFileContainer.writeColumn
> ------------------------------------------------
>
> Key: DERBY-4519
> URL: https://issues.apache.org/jira/browse/DERBY-4519
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.0.2.1, 10.1.3.1, 10.2.2.0, 10.3.3.0, 10.4.2.0,
> 10.5.3.0, 10.6.0.0
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Fix For: 10.6.0.0
>
> Attachments: derby-4519-1a-argument_swap.diff
>
>
> The offset and length argument have been swapped in the calls to
> InputStream.read(byte,offset, length) and write(byte,offset, length). This
> code is inside a do-while (true) loop, and the only normal way out is when
> InputStream.read returns -1. This will never happen since the stream is asked
> to read zero bytes. Derby ends up eating up all available CPU, limited to a
> single core / CPU.
> The bug hasn't been observed because Derby is materializing all values when
> calling this code. Enabling streaming capabilities in the sorter revealed it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
