RE: Re: music browser

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Kristian G.
Kvilekval
Sent: 19 September 2003 22:06
To: [email protected]
Subject: Re: [Zinf-devel] Re: music browser


>On Fri, 2003-09-19 at 07:01, David Hough wrote:
>> Hi,
>> 
>> In regards to the mention of a memory leak when scrolling any of the 
>> lists in musicbrowsermm, I don't know if this has been fixed yet(I'm 
>> having to use a windows only machine at the moment), but looking 
>> through the code using Browse CVS I think I found where the problem 
>> might be.
>> 
>> In GTKMusicList::scrolledwindow_changed_visible(), the line 
>> path_returned = m_listMusic.get_path_at_pos(widget_x, widget_y, 
>> NewPath, TempColumn, widget_x, widget_y); fills in the TempColumn 
>> pointer. However the object TempColumn points to is never deleted, or

>> even used for that matter. So a simple delete TempColumn;
>> after that line should fix the problem, hopefully.

>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.

If its only in the tree then it should be in
GTKLibraryTree::set_rows_data or a function called by it. However, this
shouldn't actually do anything if the row has already been displayed, as
it should only recreate the cataloginfo object (by a call to
fill_in_child) when the catalog has been changed (it checks
m_library->m_last_change, which should store the last time the catalog
has been changed).

As for the delete TempColumn causing a crash, having checked the code
again it turns out that I have actually used TempColumn in the if
statement, so it would definitly cause a crash by deleting it before
then, oops. Moving the delete TempColumn to after the if statement will
hopefully fix that, and hopefully get the leak. If it dosen't I'm at a
complete loss, I'm afraid until I a chance to actually work on the code
again.

David



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