On Tue, Apr 02, 2013 at 09:45:44PM +0200, Sebastian Ramacher wrote:
> On 2013-03-25 04:14:25, Marwan Tanager wrote:
> > > Also, I remember, that I hit a mem-leak recently when working on a
> > > poster made with LaTeX. I was recompiling the same page over and over
> > > again with LaTeX and I the memory consumption went very high. I was
> > > wondering if this is because zathura was remembering the pages from the
> > > previous versions of the recompiled document. Maybe zathura should free
> > > memory on document reloads?
> > 
> > Yes, this is an actual bug that is reported at 
> > http://bugs.pwmt.org/issue274 
> > and it should be fixed. Maybe you're the one who reported it!
> Everything except the file monitor and the zathura_t instance should be 
> released
> and re-created (if I remember that correctly), i.e. the document gets closed 
> and
> re-opened again. zathura is just a PITA to run with valgrind. There are so 
> many
> GTK related errors, that we can't fix, that valgrind's output is pretty much
> useless.
> We might have missed a free, g_object_unref, etc. somewhere of course. So
> ideas to find memory leaks without valgrind or a use-able suppression file for
> valgrind are very welcome.

I had actually done a quick scan on the code as far as freeing the memory upon 
document closing is concerned, but wasn't able to spot anything missing.  
Everything seems to be freed, the poppler pages, the widgets, the cairo 
surfaces.  But, of course, I'm not omniscient, and I could have missed 
something, too.

While thinking about this issue, I got an idea that might be related; could 
this memory be allocated to the "target" surfaces of the widgets (i.e., the 
targets of the cairo contexts that are passed to zathura_page_widget_draw), as 
opposed to the source surfaces stored in zathura_page_widget_private_s that are 
used to draw on those targets, and which now seem to be freed when the cache 
entries are invalidated?

Now, with a reasonable cache size, the rate of memory consumption is much less 
than it was before, which confirms that the source surfaces are actually freed. 
But, if memory is allocated only to the source surfaces, then the memory 
consumption should stay fixed as soon as ${page-cache-size} pages hit the 
screen. But, this is not what actually happens, and the memory consumption 
keeps increasing until each page in the document is viewed at least once.  At 
this point, no more memory is consumed while scrolling.

This makes me think that if the seemingly leaking memory is allocated to the 
target surfaces of the widgets, and GTK doesn't free this memory when freeing 
the widgets, then this might explain all of the above issues (creeping memory 
while scrolling, and after document reloads), and unfortunately, in this case, 
I think we wouldn't be able to do much about it.  So, I hope I'm wrong ;)

        Marwan Tanager
zathura mailing list

Reply via email to