On 25/08/2013 20:28, Ivan Gerasimov wrote:
I couldn't come up with any idea on how to test the overflow without
actually allocating that much memory.:
I simplified the test a bit once again. Instead of invoking the same
class twice, I created a designated class for the child.
Here's the new
On 22/08/2013 14:52, Ivan Gerasimov wrote:
Thank you Alan!
Would you please review the updated webrev?
http://cr.openjdk.java.net/~igerasim/7129312/3/webrev/
http://cr.openjdk.java.net/%7Eigerasim/7129312/2/webrev/
This looks much better (although I'm still wondering about greedy tests
Thank you Alan!
http://cr.openjdk.java.net/%7Eigerasim/7129312/2/webrev/
This looks much better (although I'm still wondering about greedy
tests wanting to reserve 4GB when running tests concurrently). But
let's go with what you have for now. One small suggestion is to assume
PARENT when
Thank you Alan!
Would you please review the updated webrev?
http://cr.openjdk.java.net/~igerasim/7129312/3/webrev/
http://cr.openjdk.java.net/%7Eigerasim/7129312/2/webrev/
On 21.08.2013 13:28, Alan Bateman wrote:
On 20/08/2013 17:01, Ivan Gerasimov wrote:
Yes, you're right!
I've updated
On 20/08/2013 17:01, Ivan Gerasimov wrote:
Yes, you're right!
I've updated the test to be a shell script + Java application.
If java reported 'Invalid maximum heap size', the test is skipped.
Just check with JPRT, the test passes on both 64 and 32 bit platforms.
Would you please review the
Thank you Alan!
The update to BufferedInputStream looks okay to me. I guess we don't
actually need to check the size in the constructor, OOME will be
thrown anyway. Usually constants are in uppercase and maybe we should
just do this while we are here (so this means rename defaultBufferSize
Just check with JPRT, the test passes on both 64 and 32 bit platforms.
Was meant: I've just checked with JPRT, and the test passes on both 64
and 32 bit platforms.
Sincerely yours,
Ivan
Hello everybody!
It was reported that BufferedInputStream#read() method may throw
NegativeArraySizeException.
This is due to doubling the buffer size in the fill() method without
checking for a possible overflow.
BUG: http://bugs.sun.com/view_bug.do?bug_id=7129312
Affected versions of jdk
Sorry, the webrev happened to be empty.
Here's the full one:
http://cr.openjdk.java.net/~igerasim/7129312/1/webrev/
http://cr.openjdk.java.net/%7Eigerasim/7129312/1/webrev/
Sincerely yours,
Ivan
On 16.08.2013 17:12, Ivan Gerasimov wrote:
Hello everybody!
It was reported that
