From: Matthias K. <Mat...@ur...> - 2006-12-28 15:20:43
|
Hi, I just hit a deadlock in audio_alsa_out caused by a race: Thread 2 (Thread -1274885216 (LWP 21350)): #0 0xffffe410 in __kernel_vsyscall () #1 0xb691e803 in poll () from /lib/tls/i686/cmov/libc.so.6 #2 0xb4069223 in ao_alsa_handle_event_thread ()=20 from /usr/lib/xine/plugins/1.1.2/xineplug_ao_out_alsa.so #3 0x00000001 in ?? () #4 0x0000014d in ?? () #5 0x00000000 in ?? () Thread 1 (Thread -1234614608 (LWP 21345)): #0 0xffffe410 in __kernel_vsyscall () #1 0xb7df56c8 in pthread_join () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xb4068091 in ao_alsa_exit ()=20 from /usr/lib/xine/plugins/1.1.2/xineplug_ao_out_alsa.so #3 0xb402cba0 in ?? () #4 0x00000000 in ?? () You should be able to reproduce the deadlock by enabling the mixer listener= =20 thread in the config and then do xine_audio_port_t *audioPort =3D xine_open_audio_driver(xineHandle, "alsa",= 0); xine_close_audio_driver(xineHandle, audioPort); at some point this->mixer.running will first be set to 0 by ao_alsa_exit an= d=20 then to 1 by ao_alsa_handle_event_thread, making the join in ao_alsa_exit=20 wait forever. I believe it can be fixed by setting this->mixer.running to 1 right before= =20 creating the new thread in ao_alsa_mixer_init. =2D-=20 ________________________________________________________ Matthias Kretz (Germany) <>< http://Vir.homelinux.org/ Mat...@gm..., kr...@kd..., Mat...@ur... |
From: Kirill B. <kir...@gm...> - 2007-01-31 18:11:55
Attachments:
alsa_race_fix.diff
|
Hi, This is a fix for the deadlock at alsa_exit first mentioned here by Matthias Kretz (email from 2006-12-28 17:20). His idea of moving 'running' variable initialization code to earlier stage works ok. This deadlock happens very often when you start playing a file and after small amount of time, stop it and close audio driver. Best regards, Kirill |
From: Miguel F. <mfr...@gm...> - 2007-02-25 21:49:02
|
On 1/31/07, Kirill Belokurov <kir...@gm...> wrote: > This is a fix for the deadlock at alsa_exit first mentioned here by > Matthias Kretz (email from 2006-12-28 17:20). His idea of moving > 'running' variable initialization code to earlier stage works ok. Thanks Kirill and Matthias. I haven't read about this issue before, your patch is clearly correct. Miguel |