Bug 16481 - Memory Leak When Converting Large SVG Files to PNG/PDF
Summary: Memory Leak When Converting Large SVG Files to PNG/PDF
Status: RESOLVED MOVED
Alias: None
Product: cairo
Classification: Unclassified
Component: svg backend (show other bugs)
Version: 1.6.4
Hardware: x86 (IA32) Linux (All)
: high major
Assignee: Emmanuel Pacaud
QA Contact: cairo-bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-06-23 09:58 UTC by Amit
Modified: 2018-08-25 13:40 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Valgrind Run 10/07/2008 (8.31 KB, text/plain)
2008-10-07 16:53 UTC, Amit
Details
Valgrind Run 10/07/2008 (8.31 KB, text/plain)
2008-10-07 16:54 UTC, Amit
Details
Valgrind Evince 10/17/2008 (6.43 KB, text/plain)
2008-10-17 16:56 UTC, Amit
Details

Description Amit 2008-06-23 09:58:30 UTC
*******
Summary
*******

I have a large PDF file from autocad that I imported into inkscape. After some editing I saved the file as an SVG. However, saving this as a PDF file causes extreme slow down to the OS. After some testing, I realized that the main cause was the memory leak. There was huge amounts of disk swapping going on.

***********
Other Notes
***********

 * I tried using other programs that use the cairo graphics library to convert the svg to pdf/png and I get the same memory leak issue described above.
  - Used rsvg-convert v. 2.22.2
  - Used pdf2svg v. 0.2.1 (http://www.cityinthesky.co.uk/pdf2svg.html)

 * The memory leak eats up most of the CPU cycles and all the RAM. It also eats up around 1.5GB of swap until I killed it manually.

 * Machine specs
  - Debian Etch
  - Linux debian 2.6.18-6-686 #1 SMP Fri Jun 6 22:22:11 UTC 2008 i686 GNU/Linux
  - Intel Pentium D 3.40GHz
  - 1GB RAM
  - 2.5GB Swap

 * Version of software (all compiled from source)
  - cairo-1.6.4
  - cairomm-1.6.0
  - inkscape 0.46
  - pixman-0.11.4
Comment 1 Chris Wilson 2008-09-28 10:04:38 UTC
Can you attach the PDF in question? Or if it contains confidential information, can you run inkscape and pdf2svg under valgrind and attach the leak report? Thankyou.
Comment 2 Amit 2008-10-07 16:53:27 UTC
Created attachment 19464 [details]
Valgrind Run 10/07/2008
Comment 3 Amit 2008-10-07 16:54:21 UTC
Created attachment 19465 [details]
Valgrind Run 10/07/2008
Comment 4 Amit 2008-10-07 16:56:19 UTC
(In reply to comment #1)
> Can you attach the PDF in question? Or if it contains confidential information,
> can you run inkscape and pdf2svg under valgrind and attach the leak report?
> Thankyou.
> 

Soon after this bug was reported, I upgraded my system to Debian Testing. I am now able to save the PDF file. However, it still eats up a lot of memory (over 1GB).

As for the pdf file, I do no think I can attach it as it has proprietary data. I ran valgrind using:

valgrind inkscape p1a.svg -A p1a.pdf

The report is attached.
Comment 5 Chris Wilson 2008-10-14 15:07:18 UTC
Yikes! I didn't realise inkscape segfaults under valgrind. The traces you've attached show a very early crash in inkscape before it even started to read the SVG. Can you try a stand-alone converter like librsvg (rsvg-convert input.svg -o output.png) and see if the memory leak occurs there as well. (As rsvg-convert is a short-lived process you'll need to run it under valgrind again with --leak-check=full, but only the "definitely lost" blocks will be relevant.)

Comment 6 Amit 2008-10-16 17:39:15 UTC
(In reply to comment #5)
> Yikes! I didn't realise inkscape segfaults under valgrind. The traces you've
> attached show a very early crash in inkscape before it even started to read the
> SVG. Can you try a stand-alone converter like librsvg (rsvg-convert input.svg
> -o output.png) and see if the memory leak occurs there as well. (As
> rsvg-convert is a short-lived process you'll need to run it under valgrind
> again with --leak-check=full, but only the "definitely lost" blocks will be
> relevant.)
> 

Ok I ran the following:

valgrind --leak-check=full rsvg-convert p1a.svg -f pdf -o p1a.pdf

It ran for about 2 mins or longer...it did not stop. I had htop running to monitor how much it was eating and it was eating all of ram and about 500MB/1024MB of swap before I had to manually kill it. Valgrind output is:

==7602== Memcheck, a memory error detector.
==7602== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==7602== Using LibVEX rev 1854, a library for dynamic binary translation.
==7602== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==7602== Using valgrind-3.3.1-Debian, a dynamic binary instrumentation framework.
==7602== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==7602== For more details, rerun with: -v
==7602== 
==7602== Warning: set address range perms: large range 252338944 (undefined)
==7602== Warning: set address range perms: large range 252338944 (undefined)
==7602== Warning: set address range perms: large range 252338944 (defined)
==7602== Warning: set address range perms: large range 252338976 (noaccess)
==7602== Warning: set address range perms: large range 189254208 (undefined)
^C==7602== 
==7602== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 124 from 2)
==7602== malloc/free: in use at exit: 697,723,462 bytes in 48,206 blocks.
==7602== malloc/free: 353,349 allocs, 305,143 frees, 1,073,694,841 bytes allocated.
==7602== For counts of detected errors, rerun with: -v
==7602== searching for pointers to 48,206 not-freed blocks.
Killed.

However, using inkscape the conversion takes less than 20 secs (although still eats meamory).

Then I ran,

valgrind --leak-check=full rsvg-convert p1a.svg -f png -o p1a.png

And I get similar outputs as above:

==9558== Memcheck, a memory error detector.
==9558== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==9558== Using LibVEX rev 1854, a library for dynamic binary translation.
==9558== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==9558== Using valgrind-3.3.1-Debian, a dynamic binary instrumentation framework.
==9558== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==9558== For more details, rerun with: -v
==9558== 
==9558== Warning: set address range perms: large range 252338944 (undefined)
Killed
Comment 7 Amit 2008-10-17 16:54:26 UTC
Some additional notes:

 - Installed 'evince-gtk' from Debian Testing (evince version 2.22.2 using poppler 0.8.7 (cairo).

 - I tried opening a large PDF file (same as below) and it eats up a lot of memory.

 - Ran: valgrind --leak-check=full evince test.pdf
  * attached valgrind report.
Comment 8 Amit 2008-10-17 16:56:36 UTC
Created attachment 19729 [details]
Valgrind Evince 10/17/2008

Valgrind run for evince.
Comment 9 GitLab Migration User 2018-08-25 13:40:20 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/cairo/cairo/issues/129.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.