[security-dev 01651]: Re: Code review request: 6880321 sun.security.provider.JavaKeyStore abuse of OOM Exception handling

Xuelei Fan Xuelei.Fan at Sun.COM
Sun Feb 28 17:34:08 PST 2010


On 2/27/2010 2:58 PM, Max (Weijun) Wang wrote:
> Hi Andrew
>
> I think the old OOME catch is to avoid invalid length value instead of real memory shortage. After IOUtils.readFully() is used, OOME occurs when there are indeed too many bytes coming and memory really not enough. I guess we can leave the system dealing with it, and that's why OOME is an Error, it's even not a RuntimeException.
>
>    
The explanation sounds. The update looks  fine to me.

Andrew
> If we catch OOME here, I believe there're too many places the same catch is needed. Of course, if you do believe 100% compatibility is a must here, I can consider it.
>
> Thanks
> Max
>
>
> On Feb 27, 2010, at 9:26 AM, Xuelei Fan wrote:
>
>    
>> Max,
>>
>> I think you still need to catch OOME exception in case of the resource exhaustation. OOME is unchecked exception, it should be converted to IOE as the old logic.
>>
>> Andrew
>>
>> On 2/26/2010 2:09 PM, Max (Weijun) Wang wrote:
>>      
>>> Hi Florian and Andrew
>>>
>>> I've created a new webrev for this bug:
>>>
>>>      http://cr.openjdk.java.net/~weijun/6880321/webrev.01
>>>
>>> This time I use the new IOUtils.readFully() method to read the stream. This method has an internal buffer that grows when more data come, and throws an EOFException (which is a child of IOException) when there're not enough bytes. I also use a temporary List to hold the certificate list.
>>>
>>> Thanks
>>> Max
>>>
>>> On Sep 22, 2009, at 6:10 PM, Xuelei Fan wrote:
>>>
>>>
>>>        
>>>> Max (Weijun) Wang wrote:
>>>>
>>>>          
>>>>> On Sep 22, 2009, at 4:09 PM, Florian Weimer wrote:
>>>>>
>>>>>
>>>>>            
>>>>>> * Max Wang:
>>>>>>
>>>>>>
>>>>>>              
>>>>>>> Please take a review on this code change:
>>>>>>>
>>>>>>>    http://cr.openjdk.java.net/~weijun/6880321/webrev.00/
>>>>>>>
>>>>>>>                
>>>>>> This code is still unreliable.  You cannot hide OutOfMemoryError this
>>>>>> way.  The error could even be thrown in a completely unrelated thread.
>>>>>>
>>>>>> There is no really good way to deal with this type of resource
>>>>>> exhaustation.  To deal with corrupted files, it is sufficient to grow
>>>>>> arrays as the file is read, so you will hit the end of the file before
>>>>>> the OOM error occurs.
>>>>>>
>>>>>>              
>>>>> This sounds better.
>>>>>
>>>>>            
>>>> Sounds better to me also.
>>>>
>>>> Andrew
>>>>
>>>>          
>>>>> Thanks
>>>>> Max
>>>>>
>>>>>
>>>>>            
>>>>>> -- 
>>>>>> Florian Weimer<fweimer at bfk.de>
>>>>>> BFK edv-consulting GmbHhttp://www.bfk.de/
>>>>>> Kriegsstraße 100              tel: +49-721-96201-1
>>>>>> D-76133 Karlsruhe             fax: +49-721-96201-99
>>>>>>
>>>>>>              
>>>>>
>>>>>            
>>>>
>>>>          
>>>
>>>        
>>      
>    




More information about the security-dev mailing list