harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [classlib][archive] problems with ZipFile
Date Mon, 30 Nov 2009 11:49:10 GMT
On 30/Nov/2009 10:32, Tim Ellison wrote:
> On 27/Nov/2009 11:30, Oliver Deakin wrote:
>> Tim Ellison wrote:
>>> <snip>
>>> FYI here is my hacked available() impl, which needs some testing before
>>> it is good to go in..
>>>   
>> With this patch for available() applied the ASN1Exception no longer gets
>> thrown in BerInputStream.read(), but instead an ASN1Exception is thrown
>> in BerInputStream.readSequence() at line 671. The message from this
>> exception is "Mandatory value is missing at [3255]".
>>
>> Looking in the byte buffer contents, I see that after index 3255 all its
>> values are 0, whereas in M11 they are all populated as expected. It
>> looks like DTD.read() is assuming that its stream.read(enc) call (around
>> line 149) will return a full buffer, but with the new zip changes it
>> does not. Applying a patch something like this (along with Tim's ZipFile
>> patch below) fixes the test failures and I get a clean run of the full
>> swing test suite:
>>
>> Index: DTD.java
>> ===================================================================
>> --- DTD.java    (revision 884214)
>> +++ DTD.java    (working copy)
>> @@ -142,8 +142,12 @@
>>
>>     public void read(final DataInputStream stream) throws IOException {
>>         // converts from DataInputStream into a byte array
>> -        byte[] enc = new byte[stream.available()];
>> -        stream.read(enc);
>> +        int available = stream.available();
>> +        byte[] enc = new byte[available];
>> +        int readBytes = 0;
>> +        while (readBytes != available) {
>> +            readBytes += stream.read(enc, readBytes, available -
>> readBytes);
>> +        }      
>>         // decode the byte array
>>         Asn1Dtd asn1 = new Asn1Dtd(enc);
> 
> 
> 
> While I agree that using available is wrong (just wanted to say that in
> every mail!), consider...
> 
> 
>   JarFile jar = new JarFile("swing.jar");
>   ZipEntry ze = jar.getEntry(NAME);
>   InputStream is = jar.getInputStream(ze);
> 
>   is.available();
>   System.out.println("Size = " + ze.getSize());
> 
>   while (is.available() > 0) {
>       int avail = is.available();
>       int i = is.read(new byte[avail]);
>       System.out.printf(
>               "Bytes requested = %d, got = %d, remaining = %d\n",
>               avail, i, is.available());
>   }
>   jar.close();
> 
> 
> On harmony (with patches) it prints:
> Size = 51140
> Bytes requested = 51140, got = 3256, remaining = 47884
> Bytes requested = 47884, got = 5072, remaining = 42812
> Bytes requested = 42812, got = 19083, remaining = 23729
> Bytes requested = 23729, got = 17749, remaining = 5980
> Bytes requested = 5980, got = 5980, remaining = 0
> 
> 
> On the RI it prints:
> Size = 51140
> Bytes requested = 51140, got = 51140, remaining = 0

The Harmony behavior is courtesy of me choosing a random 1024 byte
working buffer in the ZipInflaterInputStream hack.  We can get the data
in fewer reads by increasing it.  I updated my patch and attached it to
HARMONY-6394.

Regards,
Tim

Mime
View raw message