[alsa-devel] [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 at perex.cz>
Linux Kernel Sound Maintainer
ALSA Project; Red Hat, Inc.