[patch] more xfdesktop stuff - help wanted

[Brian J. Tarricone]

On Mon, 9 Feb 2004, Benedikt Meurer wrote:

> Brian J. Tarricone wrote:
> > i've been running xfdesktop through valgrind (--leak-check=yes 
> > --show-reachable=yes --logfile=valgrind-xfd -v --num-callers=50 
> > --leak-resolution=high), and the stack traces i get back from that do 
> > point to icon creation, but the memory allocations seem to be buried 
> > deeply in libxml2 and/or librsvg (obviously only when SVG icons are 
> > being loaded).  while i won't rule out an external bug, it just seems a 
> > bit unlikely to me that either of those two libraries could be leaking 
> > so much memory.
> 
> FYI, I've had a similar problem with a daemon program dumping 1.9GByte core 
> file after running for a day or two. After debugging for some days I found the 
> cause: I forgot one call to xmlFreeDoc(). Although the XML document in 
> question was short (only around 4Kb in text size), the in-memory tree 
> representation was that big, that parsing this file up to 100 times led to a 
> memory usage of 1.9GByte. So its not libxml2 leaking memory itself, but its 
> the programmer making small mistakes, that leads to such fast memory leaks.

yeah, that was my first thought... unfortunately i don't think that's 
it.  there's only _one_ place where i (actually whoever originally wrote 
the menu parser) am using libxml2 directly, and that's to parse the menu 
file in menu-file.c, menu_file_parse().  i've checked the function 
repeatedly, and xmlFreeDoc() appears to be called afterwards no matter 
what.

the other thing is that all the stack traces that valgrind report as 
being the causes of unfreed memory point to uses of libxml2 _inside_ 
librsvg (as called from libgdk-pixbuf).  hmm... perhaps i should 
temporarily remove SVG support and see if that solves the problem.  that 
would be quite a shame tho if it were.  ah well, i'll try that tonight 
when i get home.

argh, this is frustrating =p.

	-brian