RFR: JDK-8068427 Hashtable deserialization reconstitutes table with wrong capacity

[Peter Levart]

On 01/05/2015 03:52 PM, Daniel Fuchs wrote:
> On 04/01/15 18:58, Peter Levart wrote:
>> Hi,
>>
>> While investigating the following issue:
>>
>>      https://bugs.openjdk.java.net/browse/JDK-8029891
>>
>> I noticed there's a bug in deserialization code of java.util.Hashtable
>> (from day one probably):
>>
>>      https://bugs.openjdk.java.net/browse/JDK-8068427
>>
>> The fix is a trivial one-character replacement: '*' -> '/', but I also
>> corrected some untruthful comments in the neighbourhood (which might
>> have been true from day one, but are not any more):
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Hashtable.8068427/webrev.01/ 
>>
>
> Hi Peter,
>
> I wonder whether there should be a guard against loadFactor being
> zero/negative/NaN after line 1173, like in the constructor e.g. as
> in lines
>
>  188         if (loadFactor <= 0 || Float.isNaN(loadFactor))
>  189             throw new IllegalArgumentException("Illegal Load: 
> "+loadFactor);
>
> if only to avoid division by zero.
>
> best regards,
>
> -- daniel

Hi Daniel,

This is only possible with forged stream, right? We can extend this bug 
and make Hashtable more resilient to forged streams too.

Another check would be to limit the origlength to be no less than 
(int)(elements / loadFactor).

Can you spot any other check for an invariant that would bail out on 
forged streams?

Regards, Peter


>
>
>>
>>
>> Regards, Peter
>>
>