diff options
author | Reinhard Nißl <rnissl@gmx.de> | 2011-03-27 00:08:27 +0100 |
---|---|---|
committer | Reinhard Nißl <rnissl@gmx.de> | 2011-03-27 00:08:27 +0100 |
commit | f9f94476ee98dcda1e940f0faa279c54ce3c38ce (patch) | |
tree | 67d2fc9b737035d82da423e14899eada2c7feae9 /win32 | |
parent | 6e3610eb726674925f9c4b51aaa45f0d94bcd388 (diff) | |
download | xine-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