Re: Re: music browser

On Mon, 22 Sep 2003 15:03:21 -0700, Kristian G. Kvilekval 
<[email protected]> wrote:
>> >On Fri, 2003-09-19 at 07:01, David Hough wrote:
>
>> >Unfortunatley that wasn't,   delete'ing that causes an immediate
>> >crash.   I think it will be somewhere in the creation of
>> >cataloginfo items when the items become visible, we should only do this
>> the first time.
>>
>> Didn't you say that the leak was when you scrolled any list, not just
>> the tree? Or is the problem only in the tree?
>>
>> If its in any list then the only code that is common to all the lists is
>> GTKMusicList, and the only function called when a list is scrolled is
>> GTKMusicList::scrolledwindow_changed_visible so it must be in there
>> somewhere.
>
> Hmm.. I see your point.   It is in the playlist, tracklist, and library
> tree.
...
> I can't seem to find any documentation in gtk nor
> gtkmm about get_path_at_pos(...., TreeColumn...)
>
> I see from the source that this pointer is Glib::wrap'ed,
> but haven't found anything about that either.
>

Ok, after looking at the documentation for gtk_tree_view_get_path_at_pos 
(http://developer.gnome.org/doc/API/2.0/gtk/GtkTreeView.html#gtk-tree-view- 
get-path-at-pos) and the source code for GTKMM, it looks like I was looking 
at the wrong argument. It looks like we don't have to worry about 
TempColumn as the Wrap function means that when GTK deletes the object, 
GTKMM will delete TempColumn for us, I think anyway.
However when GTKMM calls gtk_tree_view_get_path_at_pos it takes a copy of 
the returned path, but never frees the returned path, which according to 
the GTK docs you have to do. I'm assuming this is actually the cause of our 
memory leak.

So third time lucky and all, I've written a workaround for this that means 
we use the GTK API instead of the GTKMM api for this one call, and dosen't 
take a copy of the returned path, so does free it. I've tested it in so 
much that I've made sure it dosn't break anything. Unfortunatley I don't 
have any experience in looking for memory leaks so I don't know how to 
detect them, or in this case check we don't have one anymore.

Anyway, I've made the code available as an tla/arch archive at http://www- 
student.cs.york.ac.uk/~djh123/arch/. The archive name is 
[email protected]. The code is in branch zinf--mdb which is a 
continuation from [email protected]/zinf--mdb--0.1--patch-12. If 
anyone wants the code as a normal patch, just say, and I'll try and 
generate one.

David

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf