[
https://issues.apache.org/jira/browse/DERBY-4519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Waagan updated DERBY-4519:
-----------------------------------
Attachment: derby-4519-2a-infinite_loop_fixes.diff
Patch 2a deprecates patch 1a, and it also addresses the issue (and the nit)
noted by Knut Anders.
The buffer size will now be determined by InputStream.available() given that it
returns a value between 64 and 8192 (8 KB).
Since this code path doesn't appear to be reached currently, I don't expect any
changes in behavior at this point.
The fix is an incremental improvement regardless of the exact values of the
limits , as the existing code would cause Derby to enter an infinite loop if
executed.
Patch ready for review.
> 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,
> derby-4519-2a-infinite_loop_fixes.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.
