[Gstreamer-bugs] [Bug 109069] Changed - [0.6.1 release candidate] Fix for X window leak in xvideosink plugin
bugzilla-daemon at widget.gnome.org
bugzilla-daemon at widget.gnome.org
Wed Apr 9 09:30:33 PDT 2003
Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.
http://bugzilla.gnome.org/show_bug.cgi?id=109069
Changed by in7y118 at public.uni-hamburg.de.
--- shadow/109069 Wed Apr 9 01:33:51 2003
+++ shadow/109069.tmp.4882 Wed Apr 9 12:30:33 2003
@@ -75,6 +75,23 @@
btw: Isn't 110330 a duplicate? I don't see a difference there.
------- Additional Comments From rbultje at ronald.bitfreak.net 2003-04-09 01:33 -------
It was reverted yesterday already. What's the real problem? A race?
+
+------- Additional Comments From in7y118 at public.uni-hamburg.de 2003-04-09 12:30 -------
+If you create a new GstXWindow, you obviously create a new X window,
+too. However, shared memory in X's shared memory extension is coupled
+to the X window. And since XVideosink uses a bufferpool with
+preallocated shared memory images you have to make sure to clean the
+bufferpool and other preallocated memory upon using a new window.
+
+Without the patch old buffers will simply be drawn to the old window,
+which isn't destroyed, so it works (you might lose buffers though,
+since they're all painted to the old window). With the patch attached
+here, the window is destroyed but you still get buffers with memory
+destined for the old window, which is freed, which breaks.
+With the fixes in the patch I wanted to have supplied to HEAD, but
+which hasn't shown up on the cvs-list (too tired to do the commit?),
+this is fixed and the images are properly freed when requesting a new
+window.
More information about the Gstreamer-bugs
mailing list