[OpenJDK 2D-Dev] [9] JDK-8176287 :[macosx] The print test crashed with Nimbus L&F

[Philip Race]

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.

-phil
>>
>> 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 
>> backported.
>>
> ok.
>> So "+1" with those comments ..
>>
> Thanks
>
> Regards
> Prasanta
>> -phil.
>>
>> 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.
>>>
>>> Regards
>>> Prasanta
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170313/6c8745d4/attachment.html>