rjvbb added a comment.
A priori this should be fine, and it might even address the long standing bug
by leaving more time for Phonon objects to "do their thing". It might be an
idea though to include a `qCDebug()` probe that outputs the number of items
left for auto-cleanup in `m_reusablePhonons`.
But what's the official stance on deleting objects (widgets) that have a
parent and are thus capable of auto-cleanup? AFAIK one can still delete them
explicitly, and if they're reparented during that process they should no longer
be included in the cleanup step performed by their original parent's dtor.
IOW, if you're right, isn't there a bug to address in `Phonon::MediaObject`?
There can also be another reason *in release builds* for double frees (which
your change will probably catch, too): `NotifyByAudio::notify()` does
Q_ASSERT(!m_notifications.value(m));
m_notifications.insert(m, notification);
and `NotifyByAudio::finishNotification()` does
m_notifications.remove(m);
//...
m_reusablePhonons.append(m);
Release builds do not check if `m_notifications` already contains the object
being added. It seems extremely unlikely that this would ever happen, but
apparently the code author thought it could.
REPOSITORY
R289 KNotifications
REVISION DETAIL
https://phabricator.kde.org/D6376
To: cullmann, #frameworks
Cc: rjvbb
