On Tue, 12 Apr 2016 16:52:28 +0200, Lars Lindqvist wrote:
Den 2016-04-12 skrev Takashi Iwai:
On Mon, 11 Apr 2016 17:08:01 +0200, Lars Lindqvist wrote:
On 2016-04-11 Takashi Iwai wrote:
[Added Qing Cai to Cc, who was the author of the patch in question]
On Sun, 10 Apr 2016 23:57:11 +0200, Lars Lindqvist wrote:
Hi!
Since alsa-lib commit dec428c352217010e4b8bd750d302b8062339d32, I've occationally been hit by an EBADFD whenever any program tries to play sound. The situation I get is that the first shmget succeds, so dmix->shmid >= 0, therefore first_instance = 0.
I wonder how does this succeed? It's a leftover shmem? But then why it contains the garbage...?
I seem to be able to trigger it by having one client open, starting another, and quickly closing the first one.
One possible case is that the second stream is opened almost at the same time as the first stream, and the second stream reaches to the point checking SND_PCM_DIRECT_MAGIC before the first one finishes the initialization. Does a hackish patch like below make any difference?
No it doesn't, the magic check succeeds. The situation is that the first one has been open for "a long time" when I open the second one. So I would think that initialization has been completed properly. If the second one opens just as the first closes, it might be that the second assigns (correctly) first_instance = 0, but by the time it reaches the "if (first_instance)" check, the first one has closed, and left garbage.
Actually we have a semaphore before shm access, so the race at two opens shouldn't happen. I noticed it after I sent my previous mail.
But the semaphore is taken also at snd_pcm_dmix_close(). So I wonder where the race actually happens. Both open and close must be protected while another stream is opening or closing.
Could you try to check where you get the exact error...?
Takashi