1.4-SVN [NOTstripped][validity: 1.00][frames: 2][xine]

[Jeff Mitchell]

*GUH*

I looked over that function and my brian just completely passed over the last 
line.  An unfortunate brain fart.

So here's what the situation seems to be:

getDevice was indeed creating two Medium objects from the same initial one 
before.  Only it wasn't a memory leak, because one was getting saved in the 
map, and one was getting deleted in functions that used getDevice.  This 
seems to have been the initial behavior when I wrote it.  Except that some 
functions that used getDevice weren't actually doing the delete, which, well, 
was a memory leak.

As far as I'm concerned, the initial behavior is wrong, and there's no reason 
to have two copies of the Medium object.  It can only lead to confusion, 
especially if one is still being held onto when the other changes.

So I'll go removing deletes of pointers returned from getDevice and get things 
consistent.  If people that were having these crashing issues could please 
re-test after you see the commit go through, it'd be swell.

--Jeff

On Tuesday 23 January 2007 16:44, Andrew Turner wrote:
> On 23/01/07, Jeff Mitchell <kde-dev at emailgoeshere.com> wrote:
> > Andrew--
> >
> > The only two things I can think of, considering that the call came from
> > mediumChanged, are that a receiver of the changedMedium signal is
> > deleting the Medium pointer it's sent (which it shouldn't)
>
> <snip>
>
> It does:
> void
> DeviceManager::mediumChanged( const QString name )
> {
>     DEBUG_BLOCK
>     if ( !m_valid )
>         return;
>     Medium *changedMedium = getDevice(name);
>     if ( changedMedium != 0 )
>         debug() << "[DeviceManager::mediumChanged] Obtained medium
> name is " << name << ", id is: " << changedMedium->id() << endl;
>     else
>         debug() << "[DeviceManager::mediumChanged] Obtained medium is
> null; name was " << name << endl;
>     emit mediumChanged( changedMedium, name );
>     delete changedMedium;
> }
>
> Look at the last line. I'll fix it tomorrow if nobody else has and go
> looking for other erroneous delete calls for Medium items - there seem
> to be a few in devicemanager.cpp, at least.
>
> Andrew
> _______________________________________________
> Amarok mailing list
> Amarok at kde.org
> https://mail.kde.org/mailman/listinfo/amarok