[Bug 722556] pad: Cleanup hooks on dispose

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=722556
  GStreamer | gstreamer (core) | git

--- Comment #6 from Sebastian Dröge (slomo) <slomo at coaxion.net> 2014-01-20 15:16:47 UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> > Yes, that's a big application level error if there are still pad blocks while
> > you dispose the pad. Everything should just crash then because the blocked
> > threads will use a pad that no longer exists after they were unblocked :)
> 
> Isn't the matter is that we have hooks still present, not threads actually
> being stuck?

The hooks are all freed with the clear() call below the line you added.
cleanup_hook() additionally only signals any blocked threads that they can
continue now.

> > Can you describe the actual situation a bit better?
> 
> Assume a pad callback procedure that wants to execute once and uninstall
> itself. In my case its function is to release the requested source pad (the pad
> on which actual probe is set up). But looks it can happen that task thread that
> should push through that pad is paused or stopped for some reason, and later
> the whole pipeline is shut down, so our callback haven't executed at all. This
> seems to result in a leak of memory related to that requested pad.
> 
> I cannot be sure that my description is fully correct, of course it's better to
> check with testcase than to take my speculations on trust.

Maybe a testcase would be best then... there should not be any memory leaks
here. The only problem I see that your patch can "solve" is a thread being
blocked in a pad block... while the pad is freed. And then it should crash
anyway because the thread will use this pad after the block is released (and
something should have a reference on that pad anyway).

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.