233419 - hangs when an SVG group element is enclosed within a XUL template's action block

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[Andrew Harvey]

User-Agent:       
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040207

If we wish to generate more than one SVG element every time a XUL template finds
a match, the elements must be enclosed within an SVG group. The
uri="?instancename" attribute is associated with the group.

As far as I can acertain, if the block contains an SVG element that uses units -
 for example

<svg:ellipse cx="1cm" cy="1cm"/>,

as opposed to

<svg:ellipse cx="16" cy="16"/>

- then Mozilla hangs.

In the attached example, I have included extra snippets of SVG which are
commented out. They demonstrate small variations that curiously work without a
problem.


Reproducible: Always
Steps to Reproduce:
1. Place the attached files svggrpexample.xul and svggrpexample.rdf in the same
directory.
2. Open ("File->Open File...") svggrpexample.xul within a version of Mozilla
with native SVG support.

Actual Results:  
Mozilla hangs as soon as the browser area is wiped. Excessive amounts of memory
begin to be consumed. The subsequent memory swapping degrades system performance
greatly.

Expected Results:  
Mozilla should have displayed three ellipses in the top left corner, one on top
of another. Each ellipse should belong to it's own group, and each group should
have an ID that matches the corresponding resource name in the RDF file.

Comment 1

[Andrew Harvey]

Attachment: RDF example data

Comment 2

[Andrew Harvey]

Attachment: XUL example. Open this up in a version of Mozilla with native SVG support

Comment 3

[Roland Mainz]

Can someone please attach some stack trace sampes of the "hanging" mozilla ?

Comment 4

[Andrew Harvey]

Attachment: Stack trace

A stack trace taken while Mozilla was in its hung state.

Comment 5

[Boris Zbarsky [:bzbarsky]]

I managed to get this to happen once; cpu usage was 0, so it's a deadlock (as
the stack shows) rather than an infinite loop....

Comment 6

[Andrew Harvey]

Attachment: Stack trace demonstrating a recursive loop in 'art_vpath_render_bez()'

Found this going on in another thread. ;)

GDB was unable to give me a full stack trace in a timely manner, so I have
included only the most recent frames. The 'art_vpath_render_bez()' function is
called many hundreds of thousands of times more.

CPU usage plumets while running this test, although that is most likely due to
the excessive swapping going on.

Comment 7

[Alex Fritze]

The infinite (well nearly-infinite) loop happens because there is no viewport
axis context in content/svg/content/src/nsSVGLength.cpp::mmPerPixel().
mmPerPixel returns a very small value if the context is missing, leading to a
very large path being created.

Comment 8

[Alex Fritze]

The axis context for nsSVGLengths wasn't correctly restored when content was
moved from one doc to another. This is now fixed on the trunk. 

Comment 9

[Jason Bassford]

Fixed by what?

Comment 10

[Christian :Biesinger (don't email me, ping me on IRC)]

by the checkin alex made before adding that comment?

Comment 11

[Jason Bassford]

I'm sorry - there's no explicit comment that something was actually checked in
(or by who).  Just a diagnostic comment and then a comment that it's been fixed.
 However, if that's what happened then that's good enough.

Comment 12

[Alex Fritze]

Jason: Sorry, I should have been clearer in my comment. I did check in a fix for
this problem.