Last Comment Bug 519839 - SVG fails to render correctly
: SVG fails to render correctly
Status: VERIFIED FIXED
: regression, verified1.8.1.24, verified1.9.0.15, verified1.9.1, verified1.9.2
Product: Core
Classification: Components
Component: SVG (show other bugs)
: Trunk
: All All
: P2 normal with 1 vote (vote)
: mozilla1.9.3a1
Assigned To: Wan-Teh Chang
:
Mentors:
http://upload.wikimedia.org/wikipedia...
Depends on:
Blocks: CVE-2009-0689
  Show dependency treegraph
 
Reported: 2009-09-30 15:32 PDT by Damian Shaw [Quan]
Modified: 2010-02-25 15:21 PST (History)
15 users (show)
roc: blocking1.9.2+
dveditz: blocking1.9.0.15+
hskupin: in‑testsuite?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
beta1-fixed
.4+
.4-fixed


Attachments
Wikimedia SVG (239.41 KB, image/svg+xml)
2009-09-30 15:32 PDT, Damian Shaw [Quan]
no flags Details
Incorrect rendering (89.42 KB, image/png)
2009-09-30 15:33 PDT, Damian Shaw [Quan]
no flags Details
Correct rendering (105.58 KB, image/png)
2009-09-30 15:36 PDT, Damian Shaw [Quan]
no flags Details
testcase with unnecessary stuff removed (116.44 KB, image/svg+xml)
2009-10-03 13:53 PDT, Jonathan Watt [:jwatt] (Away Jun. 27 - Jul. 13)
no flags Details

Description Damian Shaw [Quan] 2009-09-30 15:32:01 PDT
Created attachment 403884 [details]
Wikimedia SVG

STR:

1. Open attached SVG
2. Observe Europe, Africa, the Americas and part of Asia display.

Actual result:

1. Only Europe renders correctly.

Could reproduce on:

Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2b1pre) Gecko/20090930 Namoroka/3.6b1pre (.NET CLR 3.5.30729) ID:20090930051755

Could not reproduce on Firefox 3.5 on Windows XP x64.
Comment 1 Damian Shaw [Quan] 2009-09-30 15:33:49 PDT
Created attachment 403888 [details]
Incorrect rendering
Comment 2 Damian Shaw [Quan] 2009-09-30 15:36:48 PDT
Created attachment 403890 [details]
Correct rendering
Comment 3 Damian Shaw [Quan] 2009-09-30 15:38:24 PDT
Ignore the horizontal line at the top of the 2 images, just my poor screenshot taking ability.
Comment 4 Carlos Alén Silva 2009-09-30 17:38:40 PDT
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3

Same problem on Gecko 1.9.1.3/4pre on Windows XP SP 3.
Comment 5 Takeshi Kurosawa 2009-09-30 21:33:35 PDT
Works:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20090925 Minefield/3.7a1pre

Fails:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20090926 Minefield/3.7a1pre

Regression range:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=def6be3d8b6b&tochange=149c3820e8a8
Comment 6 Takeshi Kurosawa 2009-09-30 22:09:10 PDT
1.9.2 branch has same regression range.
Works:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2b1pre) Gecko/20090925 Namoroka/3.6b1pre
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/37595a72841c

Fails:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2b1pre) Gecko/20090926 Namoroka/3.6b1pre

Regression range:
http://hg.mozilla.org/releases/mozilla-1.9.2/pushloghtml?fromchange=37595a72841c&tochange=7a6b4aea8917

Perhaps, this is a regression from  Bug 414772 or bug 516396
http://hg.mozilla.org/mozilla-central/rev/ed8abff562ad
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/7a6b4aea8917
Comment 7 Robert Longson 2009-10-03 12:01:43 PDT
PR_strtod no longer accepts strings with >= 64K bytes following the check in for bug 516396

--- a/nsprpub/pr/src/misc/prdtoa.c	Fri Sep 25 18:22:48 2009 -0700
+++ b/nsprpub/pr/src/misc/prdtoa.c	Fri Sep 25 18:36:35 2009 -0700
@@ -1644,6 +1640,13 @@ PR_strtod
 
 	if (!_pr_initialized) _PR_ImplicitInitialization();
 
+	for(s = s00, i = 0; *s && i < 64 * 1024; s++, i++)
+		;
+	if (*s) {
+		PR_SetError(PR_INVALID_ARGUMENT_ERROR, 0);
+		return 0.0;
+		}
+

Here 64 * 1024 is 64 Kb and if the end of the string isn't found by then it gives up. In actual fact it needs to give up if anything that can't be part of a number (in this case a comma) is found.
Comment 8 Jonathan Watt [:jwatt] (Away Jun. 27 - Jul. 13) 2009-10-03 13:53:47 PDT
Created attachment 404447 [details]
testcase with unnecessary stuff removed
Comment 9 Wan-Teh Chang 2009-10-03 14:18:31 PDT
Robert: thanks for the explanation.  I got it now.  I will check in a fix soon.

Does SVG need to support a number longer than 64 * 1024 characters?
Comment 10 Jonathan Watt [:jwatt] (Away Jun. 27 - Jul. 13) 2009-10-03 14:36:40 PDT
SVG has the same definition or <number> as CSS does:

http://www.w3.org/TR/CSS2/syndata.html#value-def-number

There are no special requirements for the number of digits in a number that should be supported, and I've not seen any content out there with stupidly large numbers of digits. There is a lot of tool generated content with crazy long "path" data though, which it seems reasonable to be able to throw that at PR_strtod.
Comment 11 Wan-Teh Chang 2009-10-03 14:52:40 PDT
Could you test the NSPR patch in bug 516396 comment 57?  Thanks.

I just wanted to make sure PR_strtod can apply the 64K character limit
to just the number part of the input string.
Comment 12 Jonathan Watt [:jwatt] (Away Jun. 27 - Jul. 13) 2009-10-03 15:29:02 PDT
That works great, thanks!
Comment 13 Robert Longson 2009-10-03 15:31:55 PDT
(In reply to comment #9)
> Robert: thanks for the explanation.  I got it now.  I will check in a fix soon.
> 
> Does SVG need to support a number longer than 64 * 1024 characters?

No, but a path is a collection of numbers. x, y, z, etc with seaparators that may be commas or letters. We parse the first number by sending the whole string to strtod then using the second strtod argument to find where to start to consume the next element.
Comment 14 Daniel Veditz [:dveditz] 2009-10-04 15:36:00 PDT
This regression should block the 1.9.1/1.9.0 releases
Comment 15 Daniel Veditz [:dveditz] 2009-10-05 18:08:50 PDT
This should be fixed, the change that caused this was (partially) backed-out from mozilla-central, 1.9.2 and 1.9.1 (bug 516396 comment 71). Marking "fixed1.9.0.15" because although the original patch hadn't yet landed there, we do want QA to verify that the revised patch doesn't cause this regression.
Comment 16 Henrik Skupin (:whimboo) 2009-10-06 16:07:02 PDT
Verified fixed on trunk, 1.9.2, and 1.9.1 with builds on all platforms like:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20091006 Minefield/3.7a1pre ID:20091006031035

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2b1pre) Gecko/20091006 Namoroka/3.6b1pre ID:20091006034008

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4pre) Gecko/20090924 Shiretoko/3.5.4pre ID:20090924030717
Comment 17 Al Billings [:abillings] 2009-10-16 11:09:50 PDT
Comparing 1.9.0.14 and 1.9.0.15 (build 3) on Windows Vista, the SVG image renders exactly the same on both.
Comment 18 Daniel Veditz [:dveditz] 2010-02-25 15:15:02 PST
Calling this one "fixed1.8.1.24" to get some verification love: it was a regression from an early version of bug 516396's nspr patch which we have now taken on the 1.8.1 branch.
Comment 19 Al Billings [:abillings] 2010-02-25 15:21:24 PST
Verified for 1.8.1.24 using Seamonkey and attached SVG. It renders correctly now.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.24pre) Gecko/20100225 SeaMonkey/1.1.19pre

Note You need to log in before you can comment on or make changes to this bug.