]> code.delx.au - pulseaudio/commit
virtual-sink: Fix a crash when moving the sink to a new master right after setup.
authorTanu Kaskinen <tanu.kaskinen@digia.com>
Thu, 24 Feb 2011 14:16:43 +0000 (16:16 +0200)
committerColin Guthrie <cguthrie@mandriva.org>
Sat, 26 Feb 2011 10:40:06 +0000 (10:40 +0000)
commit6bd34156b130c07b130de10111a12ef6dab18b52
tree08d635f07c2165c669eed2bfcd1310babed74e38
parentb3644c1bcd5f5d73fd2dc7b898e66b11ca3ad588
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.
src/modules/module-virtual-sink.c
src/modules/rtp/rtp.h
src/pulsecore/play-memblockq.c