Bug 17771 – SVGImage accesses m_frame w/o checking for NULL

• Status: RESOLVED
• Resolution: FIXED
• Component: SVG

[Eric Seidel (no email)]

SVGImage accesses m_frame w/o checking for NULL

I don't know how to get real crashlogs out of this machine (I'm on windows for the moment).  But the top of the stack was something like this:

Frame::document()
SVGImage::hasRelativeWidth()
RenderImage::calcReplacedWidth()
RenderImage::calcPrefWidths()
RenderBox::minPrefWidth()

Looking at SVGImage.cpp it's clear we have many instances of un-guarded usage of m_frame.  I'm sure there are other crashes like this to be found.

We'll need to create a reduction (by staring @ the SVGImage source code)

[Eric Seidel (no email)]

Created attachment 19753 [details]
Fix crash

 WebCore/svg/graphics/SVGImage.cpp |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

[Eric Seidel (no email)]

(In reply to comment #1)
> Created an attachment (id=19753) [edit]
> Fix crash
> 
>  WebCore/svg/graphics/SVGImage.cpp |    8 ++++++++
>  1 files changed, 8 insertions(+), 0 deletions(-)
> 

I failed to figure out how to make a test case for this.  I've only seen this crash once, but the code definitely looks wrong.  I expect this happens when the SVGImage not yet done loading, and is asked to layout.  I tried using an empty SVGImage, but that just produced an error icon.  I also tried creating an http test, but wasn't successful.  Perhaps someone with some http test foo would like to guide me through such a process.

[Oliver Hunt]

Comment on attachment 19753 [details]
Fix crash

r=me

[Darin Adler]

Assigning to Eric, assuming he's going to land his own patch.

[Eric Seidel (no email)]

Landed as:
http://trac.webkit.org/projects/webkit/changeset/31139

I was very sad that I was not able to create a test case for this.  I'm certain there are ways to make the old code crash.