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....@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.
