SVG crashes on huge values

RESOLVED WORKSFORME

Status

()

--
critical
RESOLVED WORKSFORME
17 years ago
12 years ago

People

(Reporter: mop, Assigned: alex)

Tracking

({crash})

Trunk
x86
All
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

17 years ago
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

17 years ago
*** Bug 101302 has been marked as a duplicate of this bug. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: crash
(Reporter)

Comment 2

17 years ago
Created attachment 58880 [details]
testcase

The svg is 500x500...

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

Comment 3

17 years ago
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

17 years ago
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
Summary: SVG is corrupting memory → SVG crashes on huge values
(Assignee)

Updated

16 years ago
Depends on: 182533
(Assignee)

Updated

15 years ago
Assignee: dean.jackson → alex
(Assignee)

Comment 5

15 years ago
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.
Status: NEW → ASSIGNED

Comment 6

15 years ago
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

14 years ago
Created attachment 185245 [details]
huge % values

the testcase doesn't crash for me

this one does (huge %)

Comment 8

14 years ago
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

14 years ago
Comment on attachment 185245 [details]
huge % values

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

Does with text/xml

???
Attachment #185245 - Attachment mime type: image/svg+xml → text/xml

Updated

12 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WORKSFORME

Comment 10

12 years ago
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

12 years ago
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)
You need to log in before you can comment on or make changes to this bug.