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