[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [Bug 210427] KDE applications crash due to Phonon while playing
From:       Harald Sitter <sitter.harald () gmail ! com>
Date:       2010-11-29 9:56:26
Message-ID: 20101129095626.0BC9476143 () immanuel ! kde ! org
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=210427





--- Comment #21 from Harald Sitter <sitter harald gmail com>  2010-11-29 10:56:18 ---
Turns out this has nothing to do with race conditions.

Bug Analysis thus far:
-) upon backend change Phonon::FactoryPrivate::phononBackendChanged will be
called
-) this then calls Phonon::MediaNodePrivate::deleteBackendObject
-) and this destroys the mediaobjects and backend of the previously used
engine, however no other nodes than the mediaobjects it seems...
-) at this point the graph is left in a broken state, since any node might
access the root (or really its parent, which would probably be a mediaobject,
though that is gone too)
-) now if the consumer application destroys the nodes (usually happens on
quit), everything is fine for the mediaobject (supposedly Phonon at this point
does a roundtrip and creates an intermediate MO, since its previous one is gone
- at least I saw a second MO appear at times), but the
audiooutputs/videowidgets... are left with a broken graph and as phonon tries
to disconnect the nodes from the path it falls over, as in order to disconnect
from the rest of the graph it would have to access its parent and possible also
the root (in GStreamer most definitely the root), however there is no root, and
this is why the assert hits

Problem Analysis:
-) Backends need to keep track of all attached nodes and ensure they are shot
int he head, when the backend itself gets destructed
-) the xine backend does have a class KeepReference for this purpose, to which
each output registers and in turn KeepReference ensures that the backend holds
a list of all nodes that need cleanup
-) since this is a problem of global scope, as it potentially affects every
backend, it ought to be delt with globally, so that backend switching becomes
more reliable regardless of whether the backend implements this

Solutions:
-) Implement reference keeping in every backend (not good)
-) Ensure a backend switch enforces complete destruction of the backend's graph
(much better). I gather that the code behind
FactoryPrivate::phononBackendChanged is supposed to do exactly this, but for
whatever reason fails to do it.

FactoryPrivate::phononBackendChanged surely needs a logic review and be it only
to make it destruct the backend graph so that deletion of the parenting phonon
nodes does not crash in the backend node's dtors.

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
[prev in list] [next in list] [prev in thread] [next in thread]