Re: Re: Memleak in canvas_paint, update

Hi Al!
 Thank you so much for your reports. Using Valgrind I was able to fix 
several memory leaks, practically all. There still are a couple silly 
initialization leaks somewhere, probably in gtk or gobject, but I'm 
confident that not in gtkextra. At least the memory usage doesn't grow 
with time, and it's all freed at the end. The leaks where related to 
Pango and gtkplotbubble and gtkplotflux.
It's all in cvs.
Hopefuly you'll be able to run your code now!
Thanks again, I really appreciate it
Saludos,
<ADRIAN>

Al Hooton wrote:

>On Sat, 2004-12-04 at 08:33 -0800, Al Hooton wrote:
>
>  
>
>>I've been able to track it down to gtk_plot_canvas_paint().  I will keep
>>working to get lower in the stack...
>>    
>>
>
>	Using the gutted testgtkplotcanvas.c I sent earlier, I have spent this
>morning digging down the call stack to see what I can find.  I have
>bottomed out at gtk_plot_gdk_draw_string.  The memprof tool tells me
>this routine is where about 95% of the leaks I'm seeing are being
>caused, although it could be happening in libraries further down, but I
>don't have symbols built in those (yet).  Here's the call stack, with
>line numbers, starting at the canvas_paint call in testgtkplotcanvas:
>
>gtk_plot_canvas_paint:906
>gtk_plot_canvas_child_draw:1980
>gtk_plot_canvas_plot_draw:162
>gtk_plot_paint:1917
>gtk_plot_real_paint:2040
>gtk_plot_draw_labels:2630
>gtk_plot_draw_text:3011
>gtk_plot_pc_draw_string:264
>gtk_plot_gdk_draw_string:626
>
>	That's as far down as it goes.  The gdk_draw_string routine does it's
>thing, and the call stack unwinds all the way back up.
>
>	I have been walking through gdk_draw_string, to see if I can find
>anything obvious.  Only two things have jumped out at me, and neither of
>them takes care of the leak:
>
>- The variable "colormap" is initialized with gdk_colormap_get_system(),
>but then is not used for anything.
>
>- It appears that if (psfont->i18n_latinfamily) is true, then the
>"latin_font" variable is assigned from gtk_psfont_get_font_description,
>but it is never subsequently freed with a call to
>"pango_font_description_free), although with my lack of pango knowledge,
>I may not be understanding this correctly.
>
>	When adding test code to take care of the above items, the leaks still
>occur.
>
>	My problem now is that this is the first time I've gotten this close to
>the pango API (something I had not planned on needing to do), and I
>don't at all claim to understand the memory management
>conventions/guidelines therein.
>
>	My next step will be to fully instrument GDK and pango with symbols and
>profiling hooks (as I have done with gtkextra and GTK+), and see if I
>can get farther down the rabbit hole.  Since I've not been inside any of
>the pango stuff before. I'm not sure how much help I'll be able to
>provide in driving further debugging, but I'll keep going until the
>White Rabbit warns me against going further...   8^)=
>
>	All thoughts, suggestions, warnings, and weapons to use on my journey
>are greatly appreciated....     8^)=
>
>-Al
>
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now. 
>http://productguide.itmanagersjournal.com/
>_______________________________________________
>Scigraphica-gtkextra mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/scigraphica-gtkextra
>
>.
>
>  
>



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/