Memory leak when zooming big file

[vmerlet]

It seems there is a regression between 0.48.4 and 0.91 when handling zooming of big svg files.

I attached a sample svg file to reproduce the problem. When using 0.91 (tried the GNU/Linux and Windows-64 versions) and zooming (max factor) the center of top-right figure, the memory consuption of the system increase dramatically (it easily eats the 12Gio RAM of my system). On a machine with 4Gio RAM, it rapidly starts to swap and the computer become unresponsive.

I just tried version 0.91.0+devel+13926+58~ubuntu14.04.1 (amd64) and the problem is still there.

When doing the same with 0.48.4-3ubuntu2 (as shipped with ubuntu 14.04) this is smooth and consume at most 300Mo RAM.

Note : there is bug n°308589 showing a similar problem, but not sure it's really the same so filling a new one...

[Alvin Penner (apenner)]

- not reproduced on Windows 7, 32 bit, Inkscape 0.91 r13725 (Jan 30 2015)
   the response is admittedly slow, but not unexpectedly so, and zooming in to 25600% does not seem to make it worse.
- similar behavior on Windows XP, recent 32 bit trunk build of Inkscape.
- unfortunately I no longer have 0.48.4 available for testing.

attached is a screenshot of memory usage on Windows 7. The memory initially maxes out at 2GB, which is all there is. Then it stabilizes back to about 1.2GB and bahaves well after that. The spikes are periods where I was zooming in.

[Vladimir Savic (vladimir-firefly-savic)]

I can see the problem on this Ubuntu 14.10 computer. It's an older hardware with 3GiB of RAM. Beyond some zoom level I see a lot of swapping happening. Haven't bothered to measure exact numbers, but system does become unresponsive. Could this be related to bug #1292459 ?

[su_v (suv-lp)]

As described (excessive increased memory usage on close zooming in):
- not reproduced with Inskcape 0.58.5 r10040
- reproduced with Inkscape 0.91 r13725 and 0.91+devel r13935
on OS X 10.7.5. Inkscape 0.91+devel builds had been tested with cairo 1.12.2, 1.14.0 and recent git master (same results).

The file is also affected by
- Bug #1198317 “Dragging objects in compex document very slow in 0...”
  https://bugs.launchpad.net/inkscape/+bug/1198317

On 2015-02-21 16:23 (+0100), Vladimir Savic wrote:
> (...) Could this be related to bug #1292459 ?

Unlikely the same underlying issue - there are no pattern fills used in the sample file from comment #1. The only similarity I notice is that memory usage is immedtiately reverting to prior levels when zooming out (not a mem leak?).

[su_v (suv-lp)]

Correction (Typo in version number)
- - not reproduced with Inskcape 0.58.5 r10040
+ - not reproduced with Inkscape 0.48.5 r10040

[Alistair Muldal (alimuldal)]

I'm experiencing the same problem with Inkscape 0.91 in Ubuntu 15.04. When I open the .svg image linked above, the resident set size of Inkscape is initially about 140MB, but as I zoom in this balloons to over 6GB, I hit the swap, and my system grinds to a halt.

I'm having lots of trouble getting Inkscape 0.48.5 to compile on Ubuntu 15.04, so at the moment I can't confirm whether or not this is a regression.

[su_v (suv-lp)]

Retesting (since this report came up recently on irc too) with archived and latest trunk builds (on OS X 10.7.5):
- reproduced with rev <= 13964,
- not reproduced with rev >= 13968;
it seems this regression was fixed with the changes in r13966:
* Fix out-of-control render cache from dominating all available memory
  http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/13966

@Liam - any caveats to be considered wrt backporting to 0.91.x?

[ScislaC (scislac)]

trunk r13966 backported in 0.91.x r13772

[vmerlet (vincent-merlet)]

I retested too (ubuntu 14.04.2 amd64) :
- reproduced with rev 13965
- not reproduced with rev 13966

The commit "Fix out-of-control render cache from dominating all available memory" by Liam seems to fix this.

Thanks :-)