updated code review request: 7099399: cannot deal with CRL file larger than 16MB

[Weijun Wang]

Hi All

I've updated the webrev at

   http://cr.openjdk.java.net/~weijun/7099399/webrev.01/

I would like at least 2 reviewers. It might need to go to 7u2.

The src file is identical to the last version, and I made several 
changes to the test:

1. Now run in othervm. Though hasn't made any changes to the VM, the 
huge memory footprint might prevent other tests to be running smoothly, 
at least before a full gc.

2. It only runs on "Server" VMs now. My last JPRT test shows it failing 
on all c1 VMs and succeeding on all c2 VMs.

I just finished a new JPRT test, all builds and tests pass on supported 
platforms.

Thanks
Max


On 10/10/2011 10:59 PM, Weijun Wang wrote:
> I'm now running JPRT tests on this fix.
>
> Unfortunately, for the 6 finished tests, I've already seen linux-i586
> and solaris-i586 (both with c1 VM) failed on the new test with
>
> java.lang.OutOfMemoryError: Java heap space
>
> I guess our DER parsing codes are using too many memory. Maybe multiple
> copies of huge byte array here and there. In the short term, I'll see if
> I can rewrite the test with othervm and a proper -Xmx option.
>
> Hopefully customer dealing with these huge CRLs always use c2 VM with
> lots of memory.
>
> -Max
>
> On 10/10/2011 8:19 PM, Xuelei Fan wrote:
>> Right! Then fine to me.
>>
>> Thanks,
>> Xuelei
>>
>> On 10/11/2011 11:13 AM, Weijun Wang wrote:
>>> 0xff will be 255, -1 means no byte to read, EOF.
>>>
>>>
>>> On Oct 10, 2011, at 7:15 PM, Xuelei Fan<xuelei.fan at oracle.com> wrote:
>>>
>>>> I'm not sure why the latest byte cannot be 0xFF? What about if my
>>>> content length is 256? For example:
>>>>
>>>> 677 if (lowByte == -1) {
>>>> 678 throw new IOException("Incomplete BER/DER length info");
>>>> 679 }
>>>>
>>>> Otherwise, looks fine to me.
>>>>
>>>> Xuelei
>>>>
>>>> On 10/11/2011 9:05 AM, Weijun Wang wrote:
>>>>> Webrev at http://cr.openjdk.java.net/~weijun/7099399/webrev.00/
>>>>>
>>>>> Basically, we're now accepting X.509 block of 4-octets length. For
>>>>> simplicity, the highest byte must be<= 127, so that the length can be
>>>>> expressed with a 32-bit int.
>>>>>
>>>>> Thanks
>>>>> Max
>>>>>
>>>>>
>>>>> -------- Original Message --------
>>>>> *Change Request ID*: 7099399
>>>>> *Synopsis*: cannot deal with CRL file larger than 16MB
>>>>>
>>>>> Product: java
>>>>> Category: java
>>>>> Subcategory: classes_security
>>>>> Type: Defect
>>>>>
>>>>> === *Description*
>>>>> ============================================================
>>>>> The X.509 impl of CertificateFactory only parses X.509 blocks smaller
>>>>> than 16MB, i.e. when the length can be encoded in 3 octets. Now we
>>>>> have
>>>>> a customer whose CRL file is as big as 30MB.
>>>>>
>>>>
>>