Bug 35631 - Crash when attempting to render certain SVGs
Summary: Crash when attempting to render certain SVGs
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: SVG (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC OS X 10.5
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-02 22:59 PST by Tony Chang
Modified: 2011-01-04 03:42 PST (History)
4 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Tony Chang 2010-03-02 22:59:25 PST 
The layout test attached to bug 35261 is also crashing on Leopard Intel Debug.
https://bugs.webkit.org/attachment.cgi?id=49654&action=prettypatch

The original bug is a fix for the crash in Skia, this bug is to fix the debug only crash in CG.
Comment 1 Tony Chang 2010-03-04 00:42:21 PST 
This test is now committed at svg/custom/tiling-regular-hexagonal-crash.svg, but skipped on mac.
Comment 2 Dirk Schulze 2010-04-21 12:57:00 PDT 
(In reply to comment #1)
> This test is now committed at svg/custom/tiling-regular-hexagonal-crash.svg,
> but skipped on mac.

What is the problem here? Changing Image might help but I would like to fix the real issue.
Comment 3 Dirk Schulze 2010-04-21 13:03:42 PDT 
(In reply to comment #2)
> (In reply to comment #1)
> > This test is now committed at svg/custom/tiling-regular-hexagonal-crash.svg,
> > but skipped on mac.
> 
> What is the problem here? Changing Image might help but I would like to fix the
> real issue.

Ok, looks like the problem is a tile width or height of 0.
Comment 4 Dirk Schulze 2010-04-21 13:20:16 PDT 
Not only that we don't check for empty tile rects:

    IntSize imageSize(lroundf(patternBoundariesIncludingOverflow.width()), lroundf(patternBoundariesIncludingOverflow.height()));
    clampImageBufferSizeToViewport(document()->view(), imageSize);

    OwnPtr<ImageBuffer> patternImage = ImageBuffer::create(imageSize);

it also looks like we have a parsing bug:

height=" 270"

We don't ignore leading zeros.
Comment 5 Simon Fraser (smfr) 2010-12-18 14:39:46 PST 
Looks fine to me on SnowLeopard. Are there any remaining issues here?
Comment 6 Robert Longson 2011-01-04 03:12:08 PST 
(In reply to comment #4)
> 
> it also looks like we have a parsing bug:
> 
> height=" 270"
> 
> We don't ignore leading zeros.

It would be incorrect to ignore leading zeros. http://www.w3.org/TR/SVG/types.html#DataTypeLength
Comment 7 Dirk Schulze 2011-01-04 03:40:27 PST 
(In reply to comment #6)
> (In reply to comment #4)
> > 
> > it also looks like we have a parsing bug:
> > 
> > height=" 270"
> > 
> > We don't ignore leading zeros.
> 
> It would be incorrect to ignore leading zeros. http://www.w3.org/TR/SVG/types.html#DataTypeLength

At first sorry for my typing error, I meant spaces instead of zeros. Nevertheless, you're right Robert.

<svg xmlns="http://www.w3.org/2000/svg">
<rect x="0" y="0" width=" 100" height="10" fill="red"/>
<rect x="0" y="20" width="100 " height="10" fill="red"/>
</svg>

Both, WebKit and Firefox, don't draw the rects. And this is correct according to the spec.
Comment 8 Dirk Schulze 2011-01-04 03:42:37 PST 
The root of this problem was fixed. Closing the bug now.