[OpenJDK 2D-Dev]  JDK-8176287 :[macosx] The print test crashed with Nimbus L&F
philip.race at oracle.com
Tue Mar 14 04:54:12 UTC 2017
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.
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