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

Philip Race philip.race at oracle.com
Wed Mar 15 18:02:49 UTC 2017

I wondered that too but since it appeared we then had a loop that explicitly initialised all elements it should not matter.

But I supposed it was sort of an accidental byproduct of trying different things.

-phil.

On 3/15/17, 10:57 AM, Sergey Bylokhov wrote:

On 3/14/2017 9:51 PM, Sergey Bylokhov wrote:

14 марта 2017 г., в 14:41, Philip Race <philip.race at oracle.com_ _<mailto:philip.race at oracle.com>> написал(а):

>Since this is mac specific code, I guess VS2010 will not play any part in building this. Ah, yes :-) Updated fix looks OK. Should we memset the data allocated via malloc(calloc was used before)? Should be a good practice to do it, I guess . Modified webrev adding memset: http://cr.openjdk.java.net/~psadhukhan/8176287/webrev.02/ <http://cr.openjdk.java.net/%7Epsadhukhan/8176287/webrev.02/> This looks fine to me, but I wonder why the calloc was replaced by malloc? Regards Prasanta -phil. On 3/14/17, 2:31 AM, Prasanta Sadhukhan wrote:

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. http://cr.openjdk.java.net/~psadhukhan/8176287/webrev.01/ Regards Prasanta 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)4length); 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/20170315/19d5b13f/attachment.html>

More information about the 2d-dev mailing list