[alsa-devel] [RFC][PATCH 0/2] Fix aplay and alsa-lib write_areas() freezing with 100% cpu usage on stuck slave pcm
These patches originate from `aplay -vvv /dev/zero` not responding to Ctrl+C when playing to plugged "null", e.g. pcm.!default { type plug slave.pcm { type null } slave.format S32_LE }
First patch fixes snd_pcm_write_areas() stuck in a loop because of transfer func() always returning 0. That caused application calling it to freeze. In the example above it have frozen aplay. If it was called by firefox, it would freeze firefox.
Is it a good way to fix it? Should snd_pcm_read_areas() be fixed like that too?
Second patch fixes aplay itself, not returning from pcm_write() after SIGINT.
Additionally aplay may restore original interrupt handler, to make second Ctrl+C stop it for sure. In case of other bugs in alsa-lib or third-party slave pcms it seems better than SIGkilling it manually.
Comments and suggestions are welcome.
Regardless of these patches' fate null plugin must be fixed on its own.
Patches (2): pcm: break out of snd_pcm_write_areas() if write function returned 0 aplay: Escape from pcm_write() when in_aborting state
src/pcm/pcm.c | 2 +- aplay/aplay.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
When pcm is stuck and write func returns 0, snd_pcm_write_areas() loops infinitely freezing the application and not allowing it to handle the case. Can be reproduced with: # aplay -vvv /dev/zero pcm.!default { type plug slave.pcm { type null } slave.format S32_LE } This patch fixes it by breaking the loop if func returns 0. Note: pcm_null stuckness must be fixed on its own. --- src/pcm/pcm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/pcm/pcm.c b/src/pcm/pcm.c index 7e46014..5bb7582 100644 --- a/src/pcm/pcm.c +++ b/src/pcm/pcm.c @@ -6816,7 +6816,7 @@ snd_pcm_sframes_t snd_pcm_write_areas(snd_pcm_t *pcm, const snd_pcm_channel_area if (! frames) break; err = func(pcm, areas, offset, frames); - if (err < 0) + if (err <= 0) break; frames = err; if (state == SND_PCM_STATE_PREPARED) {
This patch fixes aplay freezing and not responding to Ctrl+C when playback pcm is stuck and returns 0 to write attempts: Example: # aplay -vvv /dev/zero pcm.!default { type plug slave.pcm { type null } slave.format S32_LE } --- aplay/aplay.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/aplay/aplay.c b/aplay/aplay.c index 77e40a3..a5b9c2a 100644 --- a/aplay/aplay.c +++ b/aplay/aplay.c @@ -1921,7 +1921,7 @@ static ssize_t pcm_write(u_char *data, size_t count) count = chunk_size; } data = remap_data(data, count); - while (count > 0) { + while (count > 0 && !in_aborting) { if (test_position) do_test_position(); check_stdin();
Date 13.6.2014 08:52, Sergey wrote:
These patches originate from `aplay -vvv /dev/zero` not responding to Ctrl+C when playing to plugged "null", e.g. pcm.!default { type plug slave.pcm { type null } slave.format S32_LE }
First patch fixes snd_pcm_write_areas() stuck in a loop because of transfer func() always returning 0. That caused application calling it to freeze. In the example above it have frozen aplay. If it was called by firefox, it would freeze firefox.
Is it a good way to fix it? Should snd_pcm_read_areas() be fixed like that too?
Nope: The whole culprit was in the null plugin - the stream was not started, thus new samples were not delivered.
I tried to fix this in:
http://git.alsa-project.org/?p=alsa-lib.git;a=commit;h=9c3086fb749cd5545be3f...
Second patch fixes aplay itself, not returning from pcm_write() after SIGINT.
Thanks, looks good, but I added the in_aborting check to other functions, too:
http://git.alsa-project.org/?p=alsa-utils.git;a=commit;h=c06dbf077459923066c...
Additionally aplay may restore original interrupt handler, to make second Ctrl+C stop it for sure. In case of other bugs in alsa-lib or third-party slave pcms it seems better than SIGkilling it manually.
Comments and suggestions are welcome.
Regardless of these patches' fate null plugin must be fixed on its own.
Patches (2): pcm: break out of snd_pcm_write_areas() if write function returned 0 aplay: Escape from pcm_write() when in_aborting state
src/pcm/pcm.c | 2 +- aplay/aplay.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
Fri, 13 Jun 2014 Jaroslav Kysela wrote:
First patch fixes snd_pcm_write_areas() stuck in a loop because of transfer func() always returning 0. That caused application calling it to freeze. In the example above it have frozen aplay. If it was called by firefox, it would freeze firefox.
Is it a good way to fix it? Should snd_pcm_read_areas() be fixed like that too?
Nope: The whole culprit was in the null plugin - the stream was not started, thus new samples were not delivered.
I tried to fix this in:
http://git.alsa-project.org/?p=alsa-lib.git;a=commit;h=9c3086fb749cd5545be3f...
Second patch fixes aplay itself, not returning from pcm_write() after SIGINT.
Thanks, looks good, but I added the in_aborting check to other functions, too:
http://git.alsa-project.org/?p=alsa-utils.git;a=commit;h=c06dbf077459923066c...
It works great. Thank you!
PS: What do you think about that small aplay patch?: http://mailman.alsa-project.org/pipermail/alsa-devel/2014-June/077665.html aplay -vvv output looks weird without it.
Date 13.6.2014 14:13, Sergey wrote:
Fri, 13 Jun 2014 Jaroslav Kysela wrote:
First patch fixes snd_pcm_write_areas() stuck in a loop because of transfer func() always returning 0. That caused application calling it to freeze. In the example above it have frozen aplay. If it was called by firefox, it would freeze firefox.
Is it a good way to fix it? Should snd_pcm_read_areas() be fixed like that too?
Nope: The whole culprit was in the null plugin - the stream was not started, thus new samples were not delivered.
I tried to fix this in:
http://git.alsa-project.org/?p=alsa-lib.git;a=commit;h=9c3086fb749cd5545be3f...
Second patch fixes aplay itself, not returning from pcm_write() after SIGINT.
Thanks, looks good, but I added the in_aborting check to other functions, too:
http://git.alsa-project.org/?p=alsa-utils.git;a=commit;h=c06dbf077459923066c...
It works great. Thank you!
PS: What do you think about that small aplay patch?: http://mailman.alsa-project.org/pipermail/alsa-devel/2014-June/077665.html aplay -vvv output looks weird without it.
Thanks. Applied now.
Jaroslav
participants (2)
-
Jaroslav Kysela -
Sergey