Bug#298225: nautilus eats all memory and dies thumbnailing .SVG file

[Ansel Sermersheim]

Josselin Mouette wrote:
> Le samedi 05 mars 2005 =C3=A0 11:38 -0800, Ansel Sermersheim a =C3=A9cr=
it :
>=20
>>Package: nautilus
>>Version: 2.8.2-2
>>Severity: normal
>>
>>
>>Apparently nautilus, or some component thereof, can't handle SVG files
>>exported from Gnumeric graphs. Enclosed is a sample SVG file created by=

>>right-clicking on a graph in Gnumeric and selecting 'Save as Image'. If=

>>I navigate in Nautilus to a directory containing this SVG, nautilus
>>becomes unresponsive, eats memory rapidly and thrashes swap until being=

>>killed and auto-restarted.
[snip]
> As the picture looks, I guess this is because the original graph
> contains some points far off the screen. This is reflected in the SVG
> file, as the SVG generator doesn't check that, and it is perfectly
> valid. However, the SVG file cannot be rendered by most SVG readers
> because they try to create a rendering area that includes these points.=

> The solution is for either gnumeric's SVG generator or librsvg's
> renderer to check that the point is off-screen and to replace it by a
> point that makes the path look the same but that's inside the rendering=

> area.

> In short, this is not really a bug but a design error. It's just like
> trying to load a 100MB JPEG file.

I see. Still, it seems ... suboptimal to have a way to cause a complete=20
denial of service on anything using SVGs in 5k. If I see a 100MB JPEG,=20
I'm *expecting* it to use a gig or two in core. I'm also expecting that, =

if I do try to open it, GIMP will be able to do it. I also expect that=20
just going to that directory in Nautilus won't choke ond die.

I haven't hand-rolled much SVG, but it looks like the root <svg> node=20
has width and height attributes. Perhaps this bugreport is really a=20
Wishlist item to have libart actually _use_ those values? Not using the=20
explicitly-defined rendering area would seem to be a bug of some kind.

Thanks for the prompt service,
-Ansel