GNOME Bugzilla – Bug 736740
glimagesink: racy redraw with raw data upload accesses deleted texture
Last modified: 2014-09-21 11:45:29 UTC
Possible sequence of events: 1. glimagesink uploads in _prepare() to texture n 1.1 glupload holds buffer n 2. glimagesink _render()s texture n 3. glimagesink uploads texture n+1 3.1 glupload free previous buffer which deletes texture n 3.2 glupload holds buffer n+1 4. glwindow resize 5. glimagesink redraws with texture n The race is that the buffer n (the one used for redrawing) is freed as soon as the buffer n+1 arrives. There could be any amount of time and number of redraws between this event and when buffer n+1 is actually rendered and thus replaces buffer n as the redraw source.
commit 5b8d7a443ead269d034401a6788f2d47f8fa4bc5 Author: Matthew Waters <ystreet00@gmail.com> Date: Sun Sep 21 21:36:49 2014 +1000 glupload: provide the output buffer that is rendered into Allows callers to properly reference count the buffers used for rendering. Fixes a redraw race in glimagesink where the previous buffer (the one used for redraw operations) is freed as soon as the next buffer is uploaded. 1. glimagesink uploads in _prepare() to texture n 1.1 glupload holds buffer n 2. glimagesink _render()s texture n 3. glimagesink uploads texture n+1 3.1 glupload free previous buffer which deletes texture n 3.2 glupload holds buffer n+1 4. glwindow resize/expose 5. glimagesink redraws with texture n The race is that the buffer n (the one used for redrawing) is freed as soon as the buffer n+1 arrives. There could be any amount of time and number of redraws between this event and when buffer n+1 is actually rendered and thus replaces buffer n as the redraw source. https://bugzilla.gnome.org/show_bug.cgi?id=736740