*CRITICAL*: Deleting bugs from iPod bug

Maximilian Kossick maximilian.kossick at googlemail.com
Tue Aug 18 08:26:44 CEST 2009


On Mon, Aug 17, 2009 at 9:33 PM, Alejandro
Wainzinger<aikawarazuni at gmail.com> wrote:
> Yeah but that's not the only multiple-spawn problem with copying, and
> I was looking to thread more copying stuff because I realized that
> what took the longest of copying isn't the KIO CopyJob, but all the
> metadata-processing code, DEBUG_BLOCK showed, so I need to thread the
> adding of metadata into the Metadata QMaps.  Unfortunately since QMap
> and friends aren't thread-safe (but re-entrant) I have to use some
> QMutexLockers and such, and figuring out how best to do it is what
> took me a bit.  Now that I'm back in Spain, I can do it with a little
> less commotion.

Ok, but that does not have anything to do with the multiple
CollectionLocation destructor calls that Seb noted in the debug
output.

> On Mon, Aug 17, 2009 at 7:15 PM, Maximilian
> Kossick<maximilian.kossick at googlemail.com> wrote:
>> On Mon, Aug 17, 2009 at 5:34 PM, Alejandro
>> Wainzinger<aikawarazuni at gmail.com> wrote:
>>> Yikes... I was doing this very thing a few days ago and didn't get
>>> this.  Compiling trunk now, checking to confirm it, and fix it ASAP.
>>> As for the multiple CollectionLocation spawning thing, I was looking
>>> into that a day or two ago but haven't finished a fix yet.  It
>>> requires creating a few more Threadweaver classes for some subjobs,
>>> and I'll get that fix in after I finish this very critical one.
>>
>> Are you sure that the spawning of multiple CollectionLocations has
>> anything to do with Threadweaver jobs? There is one call to
>> Collection::isWritable() in CollectioNTreeView::getCopyActions,
>> getMoveActions, getRemoveActions and removeTracks respectively (which
>> just happens to be the number of times the CollectionLocation dtor is
>> called in the log). Collection::isWritable() creates a
>> CollectionLocation (by calling location() on itself, so it gets the
>> correct one), checks whether it is writable and deletes the
>> CollectionLocation instance. The latter is the whole point of that
>> default implementation) by default. The easiest way to create less
>> CollectionLocations is too implement Collection::isWritable() in your
>> collection.
>>
>>> On Mon, Aug 17, 2009 at 1:27 PM, Seb Ruiz<ruiz at kde.org> wrote:
>>>> Yes, I can reproduce it.
>>>>
>>>> Here is the debug output:
>>>>
>>>> amarok: BEGIN: virtual
>>>> MediaDeviceCollectionLocation::~MediaDeviceCollectionLocation()
>>>> amarok: END__: virtual
>>>> MediaDeviceCollectionLocation::~MediaDeviceCollectionLocation() - Took
>>>> 4.4e-05s
>>>> amarok: BEGIN: virtual
>>>> MediaDeviceCollectionLocation::~MediaDeviceCollectionLocation()
>>>> amarok: END__: virtual
>>>> MediaDeviceCollectionLocation::~MediaDeviceCollectionLocation() - Took
>>>> 4.9e-05s
>>>> amarok: BEGIN: bool CollectionTreeView::onlyOneCollection(const
>>>> QModelIndexList&)
>>>> amarok: END__: bool CollectionTreeView::onlyOneCollection(const
>>>> QModelIndexList&) - Took 4.9e-05s
>>>> amarok: BEGIN: virtual
>>>> MediaDeviceCollectionLocation::~MediaDeviceCollectionLocation()
>>>> amarok: END__: virtual
>>>> MediaDeviceCollectionLocation::~MediaDeviceCollectionLocation() - Took
>>>> 4.4e-05s
>>>> amarok: BEGIN: void CollectionTreeView::removeTracks(const
>>>> QSet<CollectionTreeItem*>&) const
>>>> amarok:   BEGIN: virtual
>>>> MediaDeviceCollectionLocation::~MediaDeviceCollectionLocation()
>>>> amarok:   END__: virtual
>>>> MediaDeviceCollectionLocation::~MediaDeviceCollectionLocation() - Took
>>>> 0.00012s
>>>> amarok:   BEGIN: void CollectionLocation::prepareRemove(QueryMaker*)
>>>> amarok:   END__: void CollectionLocation::prepareRemove(QueryMaker*) -
>>>> Took 0.00015s
>>>> amarok: END__: void CollectionTreeView::removeTracks(const
>>>> QSet<CollectionTreeItem*>&) const - Took 0.00081s
>>>> amarok: BEGIN: void CollectionLocation::resultReady(const QString&,
>>>> const Meta::TrackList&)
>>>> amarok: END__: void CollectionLocation::resultReady(const QString&,
>>>> const Meta::TrackList&) - Took 0.00013s
>>>> amarok: BEGIN: void CollectionLocation::queryDone()
>>>> amarok:    we were about to remove something, lets proceed
>>>> amarok:   BEGIN: void CollectionLocation::prepareRemove(const Meta::TrackList&)
>>>> amarok:     BEGIN: void CollectionLocation::startRemoveWorkflow(const
>>>> Meta::TrackList&)
>>>> amarok:       BEGIN: virtual void
>>>> CollectionLocation::showRemoveDialog(const Meta::TrackList&)
>>>> amarok:         BEGIN: void CollectionLocation::slotFinishRemove()
>>>> amarok:         END__: void CollectionLocation::slotFinishRemove() -
>>>> Took 0.0001s
>>>> amarok:       END__: virtual void
>>>> CollectionLocation::showRemoveDialog(const Meta::TrackList&) - Took
>>>> 1.3s
>>>> amarok:     END__: void CollectionLocation::startRemoveWorkflow(const
>>>> Meta::TrackList&) - Took 1.3s
>>>> amarok:   END__: void CollectionLocation::prepareRemove(const
>>>> Meta::TrackList&) - Took 1.3s
>>>> amarok: END__: void CollectionLocation::queryDone() - Took 1.3s
>>>>
>>>>
>>>> As a side note, that's a lot of CollectionLocations that we're creating.
>>>>
>>>> Seb
>>>>
>>>> 2009/8/17 Maximilian Kossick <maximilian.kossick at googlemail.com>:
>>>>> Can you reproduce this error and provide the debug output?
>>>>>
>>>>> On Mon, Aug 17, 2009 at 12:58 PM, Seb Ruiz<ruiz at kde.org> wrote:
>>>>>> Hi Alex,
>>>>>> I stumbled across a grave bug this evening. It seems that trying to
>>>>>> delete files from the iPod immediately after copying them will infact
>>>>>> try to delete them from the collection they were copied from. Have a
>>>>>> look at the linked screenshot for evidence.
>>>>>>
>>>>>> http://img43.imageshack.us/img43/4776/amarokipod.png
>>>>>>
>>>>>> This is certainly a bug that needs to be resolved ASAP!
>>>>>>
>>>>>> Cheers,
>>>>>> Seb
>>>>>>
>>>>>> --
>>>>>> Seb Ruiz
>>>>>>
>>>>>> http://www.sebruiz.net/
>>>>>> http://amarok.kde.org/
>>>>>> _______________________________________________
>>>>>> Amarok-devel mailing list
>>>>>> Amarok-devel at kde.org
>>>>>> https://mail.kde.org/mailman/listinfo/amarok-devel
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Seb Ruiz
>>>>
>>>> http://www.sebruiz.net/
>>>> http://amarok.kde.org/
>>>> _______________________________________________
>>>> Amarok-devel mailing list
>>>> Amarok-devel at kde.org
>>>> https://mail.kde.org/mailman/listinfo/amarok-devel
>>>>
>>> _______________________________________________
>>> Amarok-devel mailing list
>>> Amarok-devel at kde.org
>>> https://mail.kde.org/mailman/listinfo/amarok-devel
>>>
>>
>


More information about the Amarok-devel mailing list