[Webkit-unassigned] [Bug 30074] New: Assertion failed, causes Safari crash from function crossing_count

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=30074

           Summary: Assertion failed, causes Safari crash from function
                    crossing_count
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Macintosh Intel
               URL: http://cartagen.org
        OS/Version: Mac OS X 10.6
            Status: UNCONFIRMED
          Severity: Major
          Priority: P2
         Component: Layout and Rendering
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: warren at mit.edu
                CC: warren at mit.edu


I'm working with a lot of canvas rendering, and I occasionally crash the
browser entirely - in the crash report, this is always present:

10/2/09 7:41:38 PM 0x0-0x424424.com.apple.Safari59690 Assertion failed: ((min.y
== p0.y && max.y == porder.y) || (min.y == porder.y && max.y == p0.y)),
function crossing_count, file Paths/path-crossing.c, line 176.

I'm new to the WebKit source and was unable to find path-crossing.c; perhaps
this is actually part of apple's CoreGraphics. A Google search reveals other
people with bugs related to this function:

http://jeremy.argoud.free.fr/lm/drawberry.txt
http://www.belightsoft.com/forum/viewtopic.php?id=4665

Both are in OSX 10.5.x

To reproduce, open http://cartagen.org in a very large window (2500px width)
and pan around with the mouse - the bug does occur in smaller windows, but a
large window will increase the chance of duplicating it.

I'm not sure what action on my part is causing this; because it crashes Safari,
it's hard to trace the call; i'm working on a pretty complex codebase, and
tracing *every* call is not feasible for performance reasons; even if I could,
I doubt I'd get to read the output before the crash occurred.

Of the googled errors I found, jeremy.argoud.free.fr's report included:

3   com.apple.CoreGraphics            0x9332a02c crossing_count + 824
4   com.apple.CoreGraphics            0x9332a5ac count_crossings_for_element +
472
5   com.apple.CoreGraphics            0x93329968 CGPathApplyByClosingSubpaths +
508
6   com.apple.CoreGraphics            0x93329a1c CGPathContainsPoint + 80

This makes me think it's related to the new isPointInPath() function of Canvas,
which ships with Safari 4. It's a very new feature:

https://bugs.webkit.org/show_bug.cgi?id=16629
Tests:
http://philip.html5.org/tests/canvas/suite/tests/index.2d.path.isPointInPath.html

but I don't believe we're using it, so that doesn't make sense. It's possible
it's called by default in some other function we're using.

The closest I could get is in CGPath.h:199

/* Return true if `point' is contained in `path'; false otherwise. A point
   is contained in a path if it is inside the painted region when the path
   is filled; if `eoFill' is true, then the even-odd fill rule is used to
   evaluate the painted region of the path, otherwise, the winding-number
   fill rule is used. If `m' is non-NULL, then the point is transformed by
   `m' before determining whether the path contains it. */

CG_EXTERN bool CGPathContainsPoint(CGPathRef path,
    const CGAffineTransform *m, CGPoint point, bool eoFill)
    CG_AVAILABLE_STARTING(__MAC_10_4, __IPHONE_2_0);


in the OSX 10.6 Frameworks, CoreGraphics.framework. This may be a red herring.

I'll update with more details and hopefully a reduced test case if possible.

If this is a problem with CoreGraphics, I'm guessing WebKit won't take the
bug... but since CoreGraphics is not open source, and WebKit is, can't we work
around it?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.