101300 - SVG crashes on huge values

Status: RESOLVED WORKSFORME

(Core :: SVG, defect)

Description

[mop]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3+) Gecko/20010908
BuildID:    

The Bug relates to the new SVG code by Alex Fritze.
go to the URL and check it out. Be warned. This SVG crashed my computer and uses
very much ressources.

According to Jon Smirl and his debug build the SVG seems to corrupt memory.

Reproducible: Always
Steps to Reproduce:
1. Install a mozilla build with the new SVG code from www.croczilla.com/svg
2. Go to the URL


Actual Results:  When loading the page mozilla takes almost every ressource it
can get and it takes VERY long to load the page. If you have bad luck this SVG
even crashes your computer.

Expected Results:  Mozilla should display the SVG much faster and should not crash.

Comment 1

[André Dahlqvist]

*** Bug 101302 has been marked as a duplicate of this bug. ***

Comment 2

[mop]

Attachment: testcase

The svg is 500x500...

And i have a rect which is out of these values. The high values let mozilla
crash....

Comment 3

[Håkan Waara]

We crash because we're trying to refresh a graphic uta (?) which is null.

Talking to mop, it seems like we have two underlying problems here:

1. We should support the viewbox stuff, so he wouldn't have to do this hack. :)
2. Per the spec, we should check for max and min values for integers/numbers
etc. I don't think we do that, do we?

Finally, we should have some better null/error -checking to paper of this bug.

Here's the stack-trace:

memset() line 108
art_uta_new(int -1, int 0, int 15626, int 15626) line 49 + 31 bytes
art_uta_new_coords(int -1, int 0, int 500001, int 500001) line 69 + 39 bytes
art_uta_from_vpath(const _ArtVpath * 0x051c8580) line 302 + 21 bytes
art_uta_from_svp(const _ArtSVP * 0x051cb070) line 49 + 9 bytes
nsSVGRenderItem::GetUta() line 50 + 12 bytes
nsSVGGraphic::Update(unsigned int 2, nsASVGGraphicSource * 0x0596632c) line 182
+ 14 bytes
nsSVGGraphicFrame::UpdateGraphic(unsigned int 2) line 290 + 46 bytes
nsSVGGraphicFrame::DidSetStyleContext(nsSVGGraphicFrame * const 0x059662f0,
nsIPresContext * 0x05156210) line 134
nsIFrame::SetStyleContext(nsIPresContext * 0x05156210, nsIStyleContext *
0x059662bc) line 549
nsSVGGraphicFrame::Init(nsSVGGraphicFrame * const 0x059662f0, nsIPresContext *
0x05156210, nsIContent * 0x0513f8b0, nsIFrame * 0x05966178, nsIStyleContext *
0x059662bc, nsIFrame * 0x00000000) line 95 + 16 bytes
nsCSSFrameConstructor::InitAndRestoreFrame(nsIPresContext * 0x05156210,
nsFrameConstructorState & {...}, nsIContent * 0x0513f8b0, nsIFrame * 0x05966178,
nsIStyleContext * 0x059662bc, nsIFrame * 0x00000000, nsIFrame * 0x059662f0) line
6533 + 32 bytes
nsCSSFrameConstructor::ConstructSVGFrame(nsIPresShell * 0x0515eb50,
nsIPresContext * 0x05156210, nsFrameConstructorState & {...}, nsIContent *
0x0513f8b0, nsIFrame * 0x05966178, nsIAtom * 0x018f2560, int 9, nsIStyleContext
* 0x059662bc, nsFrameItems & {...}) line 6911
nsCSSFrameConstructor::ConstructFrameInternal(nsIPresShell * 0x0515eb50,
nsIPresContext * 0x05156210, nsFrameConstructorState & {...}, nsIContent *
0x0513f8b0, nsIFrame * 0x05966178, nsIAtom * 0x018f2560, int 9, nsIStyleContext
* 0x059662bc, nsFrameItems & {...}, int 0) line 7115 + 49 bytes
nsCSSFrameConstructor::ConstructFrame(nsIPresShell * 0x0515eb50, nsIPresContext
* 0x05156210, nsFrameConstructorState & {...}, nsIContent * 0x0513f8b0, nsIFrame
* 0x05966178, nsFrameItems & {...}) line 6995 + 56 bytes
nsCSSFrameConstructor::ProcessChildren(nsIPresShell * 0x0515eb50, nsIPresContext
* 0x05156210, nsFrameConstructorState & {...}, nsIContent * 0x0513a210, nsIFrame
* 0x05966178, int 1, nsFrameItems & {...}, int 1, nsTableCreator * 0x00000000)
line 11749 + 66 bytes
nsCSSFrameConstructor::ConstructDocElementFrame(nsIPresShell * 0x0515eb50,
nsIPresContext * 0x05156210, nsFrameConstructorState & {...}, nsIContent *
0x0513a210, nsIFrame * 0x066989a8, nsIStyleContext * 0x05965fcc, nsIFrame * &
0x05966178) line 3392
nsCSSFrameConstructor::ContentInserted(nsCSSFrameConstructor * const 0x0515cda0,
nsIPresContext * 0x05156210, nsIContent * 0x00000000, nsIContent * 0x0513a210,
int 0, nsILayoutHistoryState * 0x00000000) line 8539
StyleSetImpl::ContentInserted(StyleSetImpl * const 0x0515ce70, nsIPresContext *
0x05156210, nsIContent * 0x00000000, nsIContent * 0x0513a210, int 0) line 1421
PresShell::InitialReflow(PresShell * const 0x0515eb50, int 14130, int 6675) line
2669
nsXMLContentSink::StartLayout() line 1674
nsXMLContentSink::DidBuildModel(nsXMLContentSink * const 0x05155980, int 1) line 356
CWellFormedDTD::DidBuildModel(CWellFormedDTD * const 0x0512d970, unsigned int 0,
int 1, nsIParser * 0x05155ad0, nsIContentSink * 0x05155980) line 310 + 20 bytes
nsParser::DidBuildModel(unsigned int 0) line 1390 + 55 bytes
nsParser::ResumeParse(int 1, int 1) line 1910
nsParser::OnStopRequest(nsParser * const 0x05155ad4, nsIRequest * 0x0514e6b0,
nsISupports * 0x00000000, unsigned int 0) line 2544 + 19 bytes
nsDocumentOpenInfo::OnStopRequest(nsDocumentOpenInfo * const 0x0514bb90,
nsIRequest * 0x0514e6b0, nsISupports * 0x00000000, unsigned int 0) line 253
nsStreamListenerTee::OnStopRequest(nsStreamListenerTee * const 0x05111de0,
nsIRequest * 0x0514e6b0, nsISupports * 0x00000000, unsigned int 0) line 25
nsHttpChannel::OnStopRequest(nsHttpChannel * const 0x0514e6b4, nsIRequest *
0x0514dbf4, nsISupports * 0x00000000, unsigned int 0) line 2316
nsOnStopRequestEvent::HandleEvent() line 177
nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x05155db4) line 80
PL_HandleEvent(PLEvent * 0x05155db4) line 590 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00a9a140) line 520 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x00000a9c, unsigned int 54006, unsigned int 0,
long 11116864) line 1071 + 9 bytes
KERNEL32! bff7363b()
KERNEL32! bff94407()

Comment 4

[Håkan Waara]

Afri, I and bbaetz has some more info on the problem here. Comments?

More info: we crash because this line fails:
  uta->utiles = art_new (ArtUtaBbox, uta->width * uta->height);
which means that later when we pass uta->utiles as a parameter, we dereference 
null.

For: <rect width="50000000" height="50000" style="fill:black;"/>, this is the 
info in the debugger:

 uta->height  1564
 uta->width   1562502

This is what bbaetz has to say:

<bbaetz> we need to:
<bbaetz> a) work out if clipping would help
<bbaetz> b) stop passing such ridiculos values down
<bbaetz> c) make libart return an error

Comment 5

[Alex Fritze]

The testcase works fine with the GDI+ backend, but not with Libart. I'm sure
GDI+ could me made to crash (or at least consume vast resources) given
appropriate testcases. tor's cairo backend might have similar problems.

As suggested in #4 we need to clip to the visible viewport area for drawing and
related ops.

Comment 6

[tor]

While a trivial bounding-box accept/reject might useful to add to the SVG
code, I think any clipping should be the responsiblity of the underlying
graphics library.

Comment 7

[Mathieu Parent]

Attachment: huge % values

the testcase doesn't crash for me

this one does (huge %)

Comment 8

[Mathieu Parent]

hang 10 seconds, then crash:
TB6352033H

http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB6352033H

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050602
Firefox/1.0+ (pacifica build)

notice that the tallback is different (different bug ?)

Comment 9

[Mathieu Parent]

Comment on attachment 185245 [details]
huge % values

strange, it doesn't crash with mime: image/svg+xml, just hangs.

Does with text/xml

???

Comment 10

[Mathieu Parent]

Ok for me also (but now, I'm Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a2pre) Gecko/20070105 Minefield/3.0a2pre ID:2007010507 [cairo]

Testing monday on windows/cairo

Comment 11

[Mathieu Parent]

Ok on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070107 Minefield/3.0a2pre too

(sorry for the bugspam)