summaryrefslogtreecommitdiff
path: root/win32
diff options
context:
space:
mode:
authorReinhard Nißl <rnissl@gmx.de>2011-03-27 00:08:27 +0100
committerReinhard Nißl <rnissl@gmx.de>2011-03-27 00:08:27 +0100
commitf9f94476ee98dcda1e940f0faa279c54ce3c38ce (patch)
tree67d2fc9b737035d82da423e14899eada2c7feae9 /win32
parent6e3610eb726674925f9c4b51aaa45f0d94bcd388 (diff)
downloadxine-lib-f9f94476ee98dcda1e940f0faa279c54ce3c38ce.tar.gz
xine-lib-f9f94476ee98dcda1e940f0faa279c54ce3c38ce.tar.bz2
Fix race condition when accessing last_frame via get_last_frame()
_x_get_current_frame_data() called get_last_frame() and locked the returned frame afterwards. At the same time, video_out_loop() unlocked last_frame to assign a different img afterwards. So in case the image got unlocked before it gets locked again, the image resides already on the free image queue. So when the image gets unlocked, it will be put a second time to the queue and hence cause a loop in the list the queue is based on. Getting an image from the queue will then run endlessly. To fix this issue, a new mutex is introduced which protects write access to last_frame and read accesses via get_last_frame() from other threads. Next, the semantic of get_last_frame() had to be changed to return a locked image already. Finally, functions calling get_last_frame() had to be adapted to its new behavior (there was only a single function in xine-lib which had to be adapted: _x_get_current_frame_data()).
Diffstat (limited to 'win32')
0 files changed, 0 insertions, 0 deletions