[OpenJDK 2D-Dev]  JDK-8176287 :[macosx] The print test crashed with Nimbus L&F
prasanta.sadhukhan at oracle.com
Tue Mar 14 09:31:27 UTC 2017
JPRT 8u build resulted in failure, so I had to modify at 2 other places.
QuartzSurfaceData.m:287 and QuartzSurfaceData.m:328
Other things remains same.
On 3/14/2017 10:47 AM, Philip Race wrote:
> On 3/13/17, 10:14 PM, Prasanta Sadhukhan wrote:
>> On 3/14/2017 10:24 AM, Philip Race wrote:
>>> The problem seems to have been that you were allocating zero bytes
>>> in the old code :
>>> 950 CGFloat* colors= (CGFloat*)calloc(0, sizeof(CGFloat)*length);
>>> 960 qsdo->gradientInfo->colordata = (CGFloat*)calloc(0,
>>> sizeof(CGFloat)*4*length); Regarding the new code, whilst it seems
>>> like it fixes the problem I have a nit
>>> 937 int i;
>>> 938 for (i=0; i<length; i++)
>>> Since this code appears at the start of a block I'd expect all
>>> compilers to be happy with
>>> for (int i=0; i<length; i++)
>>> is this not so ? Assuming yes, pls fix before push.
>> Yes, it should be ok. I got a problem with jdk8u JPRT build (during
>> earlier backport) citing C99 compiler failure but I guess that was
>> because variable was declared not at blockstart.
>> Will again do a JPRT and if its ok, I will push with this change.
> Testing the 8u backport via JPRT is good since that will use VS2010 which
> wins the "most likely to barf" award on such an issue.
>>> Also I wonder if the regression test we created for LGP passes only
>>> because it is "short".
>>> Perhaps later we can improve on that.
>>> The fix will also need to be backported since the original fix was
>>> So "+1" with those comments ..
>>> On 3/12/17, 11:49 PM, Prasanta Sadhukhan wrote:
>>>> Hi All,
>>>> Please review a jck print test crash fix for jdk9. The issue was
>>>> seen with only Nimbus L&F which seems to use Linear gradient path
>>>> and not in other L&F (such as Aqua) .
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8176287
>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8176287/webrev.00/
>>>> Linear Gradient path collects the gradient colors and fractions
>>>> values in native obtained from Java and allocates several arrays to
>>>> store the same in setupGradient() method.
>>>> It seems even after being freed, in subsequent call to the same
>>>> gradient path routine, it may get the same allocated pointer the
>>>> next time the array is allocated causing it to crash citing "memory
>>>> being modified after freed".
>>>> Optimise setupGradient() method to allocate fewer pointer. The JCK
>>>> test works now.
>>>> Also, the JDK-8162796 testcase LinearGradientPrintingTest and
>>>> RadialGradientPrintingTest works with this optimisation.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the 2d-dev