harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "spark shen (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HARMONY-5054) [ASN.1] BerInputStream will incorrectly resize buffer when the enveloped InputStream has lots of bytes
Date Thu, 01 Nov 2007 08:50:50 GMT

     [ https://issues.apache.org/jira/browse/HARMONY-5054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

spark shen updated HARMONY-5054:
--------------------------------

    Description: 
I was writing scenario test for ldap service provider, and trying to extract schema information
from an Openldap server. The response message is quite long - longer than the initial buffer
size of BerInputStream. 
While decoding the reponse, I got the following exception:


I found their are 2 problems resides in ASN.1 framework

1.  Incorrectly resize buffer
<BerInputStream.java>
137         if (buffer.length < length) {
138                byte[] newBuffer = new byte[length];
</BerInputStream.java>

And they should be modified into 
if (buffer.length < (length + offset)) {
                byte[] newBuffer = new byte[length + offset];

2. In method readContent, the if statement:

            if (in.read(buffer, offset, length) != length) {
                throw new ASN1Exception(Messages.getString("security.13C")); //$NON-NLS-1$
            }
            offset += length;
is not enough to guarantee all the bytes are read into buffer. This can be fixed using a while
loop:

            int numread = 0, oldoffset = offset;
            while ((numread = in.read(buffer, offset, length)) > 0) {
                offset += numread;
                length -= numread;
                if(length == 0) {
                    break;
                }
            }
            length = offset - oldoffset;

It's hard to write a standalone test case, due to the large number of buffer size. Writing
a scenario test would be simpler. I will provide a scenario test and the fix soon.

  was:
I was writing scenario test for ldap service provider, and trying to extract schema information
from an Openldap server. The response message is quite long - longer than the initial buffer
size of BerInputStream. While decoding the reponse, I got the following exception:


I believe the problem resides in a constructor:
<BerInputStream.java>
137         if (buffer.length < length) {
138                byte[] newBuffer = new byte[length];
</BerInputStream.java>

And they should be modified into 
if (buffer.length < (length + offset)) {
                byte[] newBuffer = new byte[length + offset];

It's hard to write a standalone test case, due to the large number of buffer size. Writing
a scenario test would be simpler. I will provide my scenario test and patch soon.


> [ASN.1] BerInputStream will incorrectly resize buffer when the enveloped InputStream
has lots of bytes
> ------------------------------------------------------------------------------------------------------
>
>                 Key: HARMONY-5054
>                 URL: https://issues.apache.org/jira/browse/HARMONY-5054
>             Project: Harmony
>          Issue Type: Bug
>          Components: Classlib
>            Reporter: spark shen
>
> I was writing scenario test for ldap service provider, and trying to extract schema information
from an Openldap server. The response message is quite long - longer than the initial buffer
size of BerInputStream. 
> While decoding the reponse, I got the following exception:
> I found their are 2 problems resides in ASN.1 framework
> 1.  Incorrectly resize buffer
> <BerInputStream.java>
> 137         if (buffer.length < length) {
> 138                byte[] newBuffer = new byte[length];
> </BerInputStream.java>
> And they should be modified into 
> if (buffer.length < (length + offset)) {
>                 byte[] newBuffer = new byte[length + offset];
> 2. In method readContent, the if statement:
>             if (in.read(buffer, offset, length) != length) {
>                 throw new ASN1Exception(Messages.getString("security.13C")); //$NON-NLS-1$
>             }
>             offset += length;
> is not enough to guarantee all the bytes are read into buffer. This can be fixed using
a while loop:
>             int numread = 0, oldoffset = offset;
>             while ((numread = in.read(buffer, offset, length)) > 0) {
>                 offset += numread;
>                 length -= numread;
>                 if(length == 0) {
>                     break;
>                 }
>             }
>             length = offset - oldoffset;
> It's hard to write a standalone test case, due to the large number of buffer size. Writing
a scenario test would be simpler. I will provide a scenario test and the fix soon.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message