Thanks!
Cheers,
Mario
On Tue 14. Jan 2020 at 22:58, Alexander Zuev
wrote:
> Hi Phil, Clemens,
>
>both code change and test looks fine to me.
>
> /Alex
>
> On 1/14/20 12:33, Phil Race wrote:
> > Here's your webrev with a jtreg compliant test added :
> >
Hi Phil, Clemens,
both code change and test looks fine to me.
/Alex
On 1/14/20 12:33, Phil Race wrote:
Here's your webrev with a jtreg compliant test added :
http://cr.openjdk.java.net/~prr/8235904/
I verified the test behaves properly under jtreg -
before the fix jtreg kills it on time
Here's your webrev with a jtreg compliant test added :
http://cr.openjdk.java.net/~prr/8235904/
I verified the test behaves properly under jtreg -
before the fix jtreg kills it on time out
after the fix it finishes quickly and successfully
Outside of jtreg it also exits properly although
Hi Clemens,
That needs reworking in location as well as adding jtreg boiler plate and legal
notice. Also there are code changes required to be a well behaved test. I need
to sit in front of a headful Linux system to test those so I will have to
follow up on this (hopefully) tomorrow.
-Phil.
Hi Phil,
> Is there a regression test ?
> I don't see a noreg- label.
Sorry I forgot to mention, the regression test is in the "main"
directory of the bugfix:
http://cr.openjdk.java.net/~ceisserer/8235904/
Thanks and best regards, Clemens
Is there a regression test ?
I don't see a noreg- label.
-phil.
On 1/9/20, 12:51 AM, Clemens Eisserer wrote:
Hi,
Please review the fix for bug 8235904 "Infinite loop when rendering
huge lines": http://cr.openjdk.java.net/~ceisserer/8235904/webrev.01/
The issue was caused by integer overflow
Hi Clemens,
Thanks for the patch, the fix looks good to me. I'm not a reviewer
however so I can't approve the push...
Cheers,
Mario
On Thu, Jan 9, 2020 at 9:51 AM Clemens Eisserer wrote:
>
> Hi,
>
> Please review the fix for bug 8235904 "Infinite loop when rendering
> huge lines":
Hi,
Please review the fix for bug 8235904 "Infinite loop when rendering
huge lines": http://cr.openjdk.java.net/~ceisserer/8235904/webrev.01/
The issue was caused by integer overflow during clipping: While the
original native code used int or long depending on the coordinate
range, the java-port
