diff options
author | Tanu Kaskinen <tanu.kaskinen@digia.com> | 2011-02-24 16:16:43 +0200 |
---|---|---|
committer | Colin Guthrie <cguthrie@mandriva.org> | 2011-02-26 10:40:06 +0000 |
commit | 6bd34156b130c07b130de10111a12ef6dab18b52 (patch) | |
tree | 08d635f07c2165c669eed2bfcd1310babed74e38 /src/pulsecore/socket-util.c | |
parent | b3644c1bcd5f5d73fd2dc7b898e66b11ca3ad588 (diff) |
virtual-sink: Fix a crash when moving the sink to a new master right after setup.
If the virtual sink is moved to a new master right after it has been created,
then the virtual sink input's memblockq can be rewound to a negative read
index. The data written prior to the move starts from index zero, so after the
rewind there's a bit of silence. If the memblockq doesn't have a silence
memchunk set, then pa_memblockq_peek() will return zero in such case, and the
returned memchunk's memblock pointer will be NULL.
That scenario wasn't taken into account in the implementation of
sink_input_pop_cb. Setting a silence memchunk for the memblockq solves this
problem, because pa_memblock_peek() will now return a valid memblock if the
read index happens to point to a hole in the memblockq.
I believe this isn't the best possible solution, though. It doesn't really make
sense to rewind the sink input's memblockq beyond index 0 in the first place,
because now when the stream starts to play to the new master sink, there's some
unnecessary silence before the actual data starts. This is a small problem,
though, and I don't grok the rewinding system well enough to know how to fix
this issue properly.
I went through all files that call pa_memblockq_peek() to see if there are more
similar bugs. play-memblockq.c was the only one that looked to me like it might
be broken in the same way. I didn't try reproducing the bug with
play-memblockq.c, though, so I just added a FIXME comment there.
Diffstat (limited to 'src/pulsecore/socket-util.c')
0 files changed, 0 insertions, 0 deletions