Hi Phil,
The change looks fine.
Jennifer
On 10/27/2014 02:49 PM, Phil Race wrote:
I can add othervm but each VM invocation slows down the
overall testing time and I'd like to think this only will be run on
versions that do not have the bug.
I added the custom time out code so that I was not reliant on the
harness to test.
Certainly I can delete all of that and just go to
@run main/othervm/timeout=60
60 up from 15 because it needs to include othervm overhead and
avoid/minimise spurious failures
See http://cr.openjdk.java.net/~prr/8028539.1/
-phil.
On 10/27/2014 2:10 PM, Jim Graham wrote:
The fix looks fine. Isn't there a timeout you can set on the unit
test rather than rolling your own inside the test? Also, even if you
interrupt the test, if the failure mode is an infinite loop in native
code then the VM you are running in is probably not going to be
happy. That only happens when the test fails, but is it worth running
in a separate VM just in case?
...jim
On 10/27/14 1:51 PM, Phil Race wrote:
https://bugs.openjdk.java.net/browse/JDK-8028539
http://cr.openjdk.java.net/~prr/8028539/
The trigger for the bug is that there is a translate component on the
graphics
which overflows what can be stored in a integer, and the native code we
reach
cannot handle this.
Although the sofware loops was hanging, additionally D3D and OGL on
Windows
were not clipping this properly. The rendering appeared on screen
when it
should have been clipped.
The fix is to add a test to see if any value overflows and then punt to
the TransformHelper code which can handle and clip this properly.
-phil.
