[ 
https://issues.apache.org/jira/browse/HBASE-17258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15722063#comment-15722063
 ] 

Anoop Sam John commented on HBASE-17258:
----------------------------------------

So u r saying abt the MBB create and usage in the write path now..  So this 
means we flow expect MBB to have an int but those many bytes not there!.  This 
can happen if the incoming req bytes were some how truncated..   But then we 
have check much before these processing..  We have 1st 4 bytes of req as the 
total req bytes length.  We make MBB as per this length and then read into it.  
If we are not able to get those many bytes, we will throw exception there 
itself..   So I would say chance of this issue coming in write path also very 
less.. or not possible..
For completion of the API as such I am ok to add the check..  As said , many 
checks possible in MBB, we avoided..   So this way it would be possible to see 
many gaps.. Am not sure whether to add checks all those places..  Am ok to add 
this check.  Not a costly thing at all.

> MultiByteBuff#getXXX() has issues
> ---------------------------------
>
>                 Key: HBASE-17258
>                 URL: https://issues.apache.org/jira/browse/HBASE-17258
>             Project: HBase
>          Issue Type: Bug
>    Affects Versions: 2.0.0
>            Reporter: ramkrishna.s.vasudevan
>            Assignee: ramkrishna.s.vasudevan
>            Priority: Minor
>         Attachments: HBASE-17258.patch
>
>
> MBB#getInt() - the relative getXXX() API has issues.
> {code}
> int remaining = this.curItem.remaining();
>     if (remaining >= Bytes.SIZEOF_INT) {
>       return this.curItem.getInt();
>     }
>     if (remaining == 0) {
>       if (items.length - 1 == this.curItemIndex) {
>         // means cur item is the last one and we wont be able to read a long. 
> Throw exception
>         throw new BufferUnderflowException();
>       }
>       this.curItemIndex++;
>       this.curItem = this.items[this.curItemIndex];
>       return this.curItem.getInt();
>     }
> {code}
> Now here if the curItem does not have anything remaining in it we just go to 
> the nextItem and from that we do a getInt. But we don't check if that item is 
> big enough to return an int. This may not happen in most of the real cases  
> but as an API it should handle that case. Since MBB are now used in the 
> RpcServer#response there could be some on demand BB created that are smaller 
> in sizes and it could lead to issues.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to