Bug 84737 - Memory leak (reloading the same file increases memory consumption)
Summary: Memory leak (reloading the same file increases memory consumption)
Status: RESOLVED MOVED
Alias: None
Product: poppler
Classification: Unclassified
Component: glib frontend (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: poppler-bugs
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-10-07 08:04 UTC by Phillip Berndt
Modified: 2018-08-21 11:13 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Test program (1.24 KB, text/plain)
2014-10-07 08:04 UTC, Phillip Berndt
Details
Valgind output (475.78 KB, text/plain)
2014-10-07 08:28 UTC, Phillip Berndt
Details
Longer valgrind run, only the last two warnings (5.70 KB, text/plain)
2014-10-07 08:37 UTC, Phillip Berndt
Details
Example PDF (282.27 KB, application/pdf)
2014-10-26 16:14 UTC, Phillip Berndt
Details

Description Phillip Berndt 2014-10-07 08:04:45 UTC
Created attachment 107455 [details]
Test program

The attached test program loads a PDF file, draws it, unloads the file, and then starts over again. To compile it, use

 cc test.c -o test $(pkg-config --libs --cflags gtk+-3.0 glib-2.0 cairo gio-2.0 poppler-glib)

and then start it with a PDF file as its first argument, preferably a large one, like a paper or a book.

I'd expect _some_, _limited_ growth in memory consumption, due to things like caching, but instead memory usage appears to grow linearly. With a 147kB PDF, I'm at 1.5GB memory consumption after some minutes. I tested this with Poppler 0.24.5 and 0.26.5, but not with the latest git version, on a machine running Ubuntu Trusty.

If I run the same program with a gdk-pixbuf and images instead of poppler, memory consumption does not increase, so I am quite positive that this is indeed a poppler bug and not one in gtk/glib. I did not make any attempts to find the source within poppler though, so I can't tell if this really is a problem in the glib frontend or if the problem lies in the backend.
Comment 1 Albert Astals Cid 2014-10-07 08:07:26 UTC
You should run valgrind with --leak-check=full and attach the result of valgrind.

That will tell us where the leak is.
Comment 2 Phillip Berndt 2014-10-07 08:28:31 UTC
Created attachment 107456 [details]
Valgind output

Done, with the latest git version of poppler, 4fe17e9.

I did not let the program run long this time, so there's not much to see. The two last messages in the file seem to be the most interesting ones. It seems as if memory is lost in the cairo backend while handling fonts.
Comment 3 Phillip Berndt 2014-10-07 08:37:00 UTC
Created attachment 107458 [details]
Longer valgrind run, only the last two warnings

A longer run confirmed that: The clutter remains the same, but the two GfxFont messages grow in size. I'll attach them.
Comment 4 Albert Astals Cid 2014-10-26 15:54:13 UTC
Please attach the pdf file you're using for this
Comment 5 Phillip Berndt 2014-10-26 16:14:00 UTC
Created attachment 108458 [details]
Example PDF

The problem occurs for all PDF files, that's why I didn't attach one. But here's a random one from google where the example program uses ~2.5 GB of ram after 5 minutes.
Comment 6 GitLab Migration User 2018-08-21 11:13:04 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/poppler/poppler/issues/569.


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.