[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