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
