[Bug 771326] Fix memory leak: QCoreApplication::postEvent with DeactivateEvent never execute.

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Thu Sep 15 06:33:12 UTC 2016


https://bugzilla.gnome.org/show_bug.cgi?id=771326

George Kiagiadakis <gkiagia at tolabaki.gr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |gkiagia at tolabaki.gr
         Resolution|---                         |INVALID

--- Comment #1 from George Kiagiadakis <gkiagia at tolabaki.gr> ---
I'm sorry, but this is wrong. There is a reason why the code calls postEvent()
there instead of sendEvent(). 

With your patch, the event delivery becomes synchronous, which means that the
thread that executes the element's state change will also deliver the event in
the context of the state change. This is wrong because in GStreamer you cannot
guarantee that the thread which executes the state change is the same as the
main GUI thread, and in case the event is delivered in the wrong thread, the
event loop will most likely crash (sendEvent() is *not* thread-safe).
postEvent() on the other hand ensures that the event delivery happens in the
correct thread, no matter which thread the event was sent from.

The real problem in your example is that your pipeline changes state to Null
*after* the event loop terminates! The ~Player() destructor is called when
main() terminates, after QCoreApplication::exec() has returned, so it is
reasonable in this case for a leak to happen, since the event is posted to a
non-existent event loop. It is generally a bad practice in Qt applications to
allocate objects on the stack in main() because of that. Instead, allocate it
on the heap and hook its destruction to the QCoreApplication::aboutToQuit()
signal. This will ensure that everything cleans up properly before the event
loop terminates.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list