When looking at the valgrind log from a simple poppler-glib program to extract plain text content from a pdf (http://git.gnome.org/browse/tracker/tree/src/tracker-extract/tracker-extract-pdf.c) I can see that fonts fd are not released (using poppler 0.12.3). This module is loaded in another program, which will run out of free fds after a certain number of calls. There's a patch for that in the git version of poppler : 65fba0aac7d60a0ff2ae26f21d99673de8a9de74 . Could this patch be backported in the next stable version ? I could cherry-pick it against the 0.12.3 tag without any problem.
Which poppler revision do you mean? Revision 65fba0aac7d60a0ff2ae26f21d99673de8a9de74 doesn't exist in poppler git repo.
I think this should have been 6825a219f0bc0ac6fd469fb8a6ebb86df774375f
That commit should fix the problem for you because it doesn't use CairoOutputdev anymore, but not the bug since there seems to be a leak in CairoOutputDev, maybe this one: http://cgit.freedesktop.org/poppler/poppler/commit/?h=poppler-0.12&id=e25e4fd2e76619dd42715a1e9d78088850d8fe7e that was comitted after 0.12.3, could you confirm this commit fixes the problem? I can backport the other commit too if it works better for you anyway.
Created attachment 33034 [details] Valgrind logs showing "leaked" fds at the top Nope, that commit doesn't fix my bug, I still have opened file descriptors when the program exits (still the fonts). Attached is my valgrind log, the "leaked" fds are at the top.
I think it's a cairo issue, we use cairo_font_face_set_user_data() to close the file descriptor when the font is destroyed, but fonts are never destroyed. Cairo holds references of the fonts that are never released.
Moving to cairo
Cairo holds a large (256) scaled-font holdover cache because a lot of applications create, destroy and then recreate the small working set of fonts regularly. However, in situations such as this you will then need to exercise poppler with a large number of fonts before you see evictions. During shutdown, in order to fully clean up global caches you need to call cairo_debug_reset_static_data() [as well as all the other per library cleanup routines]. This is only recommended during leak checking, at all other times is simply more efficient to let the OS reap the resources upon exit(). Since the test case is behaving exactly as designed, I do not see the bug...
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.