Created attachment 69294 [details]
Trace file for borderRadiusDashed04 test case

This trace file writes broderRadiusDashed04.png correctly before the offending patch. 

It causes a segmentation fault after the offending commit cd1004ce.

Created attachment 69295 [details]
BorderRadiusDashed04.png

Correct output

The trace doesn't crash here, but it does exhibit the unusual behaviour of the dash around the corners...

Looks correct in epiphany (WebKit/gtk).

I'm starting to lose hope that  ./Tools/Scripts/build-webkit --efl --update-efl
will ever succeed :-p

(In reply to comment #4)
> Looks correct in epiphany (WebKit/gtk).

Against older system cairo? Or against 1.12.4?

> I'm starting to lose hope that  ./Tools/Scripts/build-webkit --efl
> --update-efl
> will ever succeed :-p

You can come to #webkit-efl on freenode, we're there to help.

(In reply to comment #5)
> (In reply to comment #4)
> > Looks correct in epiphany (WebKit/gtk).
> 
> Against older system cairo? Or against 1.12.4?

With git.

(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > Looks correct in epiphany (WebKit/gtk).
> > 
> > Against older system cairo? Or against 1.12.4?
> 
> With git.

Are you sure Epiphany picked up the right cairo library? We do see those cases fail in WebKit EFL ToT against cairo 1.12.4. Maybe a later commit fixed the crash, but the rendering is still flawed there, as you mentioned in comment 3.

epiphany is picking up the right version of cairo and appears to render correctly. The trace is bizarre in that the red dashes appear to be clipped, that the line width appears to be much larger than the blue. Even more bizarre is that the blue is first drawn much wider and looks like the red then is redrawn correctly.

Is there a chance you can grab a bt from the crash?

(In reply to comment #9)
> Is there a chance you can grab a bt from the crash?

I'll see what I can do, will also check the trace again.

(In reply to comment #10)
> (In reply to comment #9)
> > Is there a chance you can grab a bt from the crash?

http://pastebin.com/mRSBnkDh
Seems to be infinite recursion from  _cairo_surface_stroke.

(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #9)
> > > Is there a chance you can grab a bt from the crash?
> 
> http://pastebin.com/mRSBnkDh
> Seems to be infinite recursion from  _cairo_surface_stroke.

This was with cairo @cd1004ce19c7ea28c7fedb64.

* scratches head.

That should be impossible... The next task is working out where exactly we decide we cannot use the span compositor to draw the stroke. The clue has to be cd1004ce.

(In reply to comment #13)
> * scratches head.
> 
> That should be impossible... The next task is working out where exactly we
> decide we cannot use the span compositor to draw the stroke. The clue has to
> be cd1004ce.

The recursion crash is gone in 1.12.4 and 1.12.6, some later commit made it go away. 

What I also tried is applying your fix from bug 56432 and try the first two test cases again. Rendering of fast/borders/borderRadiusAllStylesAllCorners.html is improved (i.e. no round joins anymore), but still too thick stroking and some double/overlay/extra stroking in incorrect places.

Created attachment 69353 [details]
Trace file for borderRadiusDashed04 test case (new)

Is this trace file better? When I csi-exec this one, it shows exactly the same failure as in the WebKit layout test.

Created attachment 69354 [details]
Trace file for borderRadiusAllStylesAllCorners.html

(In reply to comment #14)
> (In reply to comment #13)
> > * scratches head.
> > 
> > That should be impossible... The next task is working out where exactly we
> > decide we cannot use the span compositor to draw the stroke. The clue has to
> > be cd1004ce.
> 
> The recursion crash is gone in 1.12.4 and 1.12.6, some later commit made it
> go away. 

Not intentionally. If it is easy enough, can you do a reversed bisect to find the fix? I still think that recursion should be prevented by design, so indicates a real bug somewhere that may just be masked.

> What I also tried is applying your fix from bug 56432 and try the first two
> test cases again. Rendering of
> fast/borders/borderRadiusAllStylesAllCorners.html is improved (i.e. no round
> joins anymore), but still too thick stroking and some double/overlay/extra
> stroking in incorrect places.

Right, that's the bizarreness in the rendering I see in the attached trace.

(In reply to comment #17)

> Not intentionally. If it is easy enough, can you do a reversed bisect to
> find the fix? I still think that recursion should be prevented by design, so
> indicates a real bug somewhere that may just be masked.

Next commit, 4ea3ace6c810ba090464e, actually makes the crash go away.

Ok, that took a lot of digging to spot that the clip wasn't being performed at all..

commit b6daf47fa08c74d9672040b2b98ac6dd1f841429
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Nov 1 08:39:01 2012 +0000

    spans: Do not assume that we manage to perform the clip geometrically
    
    Even for bounded masks, we may fail to perform the clipping
    geometrically for a variety of reasons, the prime one being that the
    clip has a mixture of antialias settings. So when compositing the
    polygon, we need to check whether a clip path still remains and so
    requires a clipmask.
    
    Fixes regression from
    
    commit cd1004ce19c7ea28c7fedb6464562a08416586c0
    Author: Chris Wilson <chris@chris-wilson.co.uk>
    Date:   Fri May 11 21:20:35 2012 +0100
    
        traps,spans-compositor: Avoid mistreating unaligned clips as aligned
    
    and
    
    commit 4ea3ace6c810ba090464e48795fac5456f6cdc24
    Author: Chris Wilson <chris@chris-wilson.co.uk>
    Date:   Fri May 11 21:51:44 2012 +0100
    
        spans: Only fallback for a clipmask if unbounded
    
    Reported-by: Dominik Röttsches <dominik.rottsches@intel.com>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56574
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>