| Summary: | Memory Leak When Converting Large SVG Files to PNG/PDF | ||
|---|---|---|---|
| Product: | cairo | Reporter: | Amit <amit.uttam> |
| Component: | svg backend | Assignee: | Emmanuel Pacaud <emmanuel.pacaud> |
| Status: | RESOLVED MOVED | QA Contact: | cairo-bugs mailing list <cairo-bugs> |
| Severity: | major | ||
| Priority: | high | ||
| Version: | 1.6.4 | ||
| Hardware: | x86 (IA32) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
Valgrind Run 10/07/2008
Valgrind Run 10/07/2008 Valgrind Evince 10/17/2008 |
||
|
Description
Amit
2008-06-23 09:58:30 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. Created attachment 19464 [details]
Valgrind Run 10/07/2008
Created attachment 19465 [details]
Valgrind Run 10/07/2008
(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. 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.) (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 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. Created attachment 19729 [details]
Valgrind Evince 10/17/2008
Valgrind run for evince.
-- 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.