[RFC][PATCH 0/2] Fix aplay and alsa-lib write_areas() freezing with 100% cpu usage on stuck slave pcm

[RFC][PATCH 0/2] Fix aplay and alsa-lib write_areas() freezing with 100% cpu usage on stuck slave pcm

[Sergey]

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(-)

-- 
1.7.10.4
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

[PATCH 1/2] pcm: break out of snd_pcm_write_areas() if write function returned 0

[Sergey]

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) {
-- 
1.7.10.4

[PATCH 2/2] aplay: Escape from pcm_write() when in_aborting state

[Sergey]

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();
-- 
1.7.10.4

Re: [RFC][PATCH 0/2] Fix aplay and alsa-lib write_areas() freezing with 100% cpu usage on stuck slave pcm

[Jaroslav Kysela]

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=9c3086fb749cd5545be3f15cdde1592390006258

> 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=c06dbf077459923066c96556678835cd1f55123a

> 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(-)
> 


-- 
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project; Red Hat, Inc.

Re: [RFC][PATCH 0/2] Fix aplay and alsa-lib write_areas() freezing with 100% cpu usage on stuck slave pcm

[Sergey]

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=9c3086fb749cd5545be3f15cdde1592390006258
>
>> 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=c06dbf077459923066c96556678835cd1f55123a

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.

-- 
  Sergey

fprintf(stderr, "%-20.*s %i%%\n", perc[0]/5, "####################", perc[0]);

Re: [RFC][PATCH 0/2] Fix aplay and alsa-lib write_areas() freezing with 100% cpu usage on stuck slave pcm

[Jaroslav Kysela]

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=9c3086fb749cd5545be3f15cdde1592390006258
>>
>>> 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=c06dbf077459923066c96556678835cd1f55123a
> 
> 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


-- 
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project; Red Hat, Inc.