From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47393) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y0Rda-0005H2-4M for qemu-devel@nongnu.org; Mon, 15 Dec 2014 04:08:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y0RdU-0004kq-N0 for qemu-devel@nongnu.org; Mon, 15 Dec 2014 04:08:18 -0500 Received: from mx1.redhat.com ([209.132.183.28]:34500) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y0RdU-0004kh-ET for qemu-devel@nongnu.org; Mon, 15 Dec 2014 04:08:12 -0500 From: Markus Armbruster References: Date: Mon, 15 Dec 2014 10:08:07 +0100 In-Reply-To: (Peter Maydell's message of "Fri, 12 Dec 2014 16:47:46 +0000") Message-ID: <87fvchffgo.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] paaudio race condition on close List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: QEMU Developers , Gerd Hoffmann If Gerd (cc'ed) doesn't know, then I'm afraid nobody around here does. Peter Maydell writes: > There seems to be a race condition in the pulseaudio backend on > closing of a voice... > > There are two threads involved here. The first one is a worker > thread that just sits executing our qpa_thread_in() function > to get input audio from PA and feed it to us. The second thread > is QEMU itself (the cpu thread in the case of TCG), which calls > AUD_close_in(): > > #0 0x00007ffff054466b in pthread_join (threadid=140736709240576, > thread_return=0x7fffdfdcc130) > at pthread_join.c:92 > #1 0x00005555557def8f in audio_pt_join (p=0x7fffbc0195b8, arg=0x7fffdfdcc178, > cap=0x555555b0dfd5 <__FUNCTION__.21892> "qpa_fini_in") > at /home/petmay01/linaro/qemu-from-laptop/qemu/audio/audio_pt_int.c:166 > #2 0x00005555557ddec7 in qpa_fini_in (hw=0x7fffbc019520) > at /home/petmay01/linaro/qemu-from-laptop/qemu/audio/paaudio.c:689 > #3 0x00005555557d3cab in audio_pcm_hw_gc_in (hwp=0x7fffbc032c28) > at /home/petmay01/linaro/qemu-from-laptop/qemu/audio/audio_template.h:196 > #4 0x00005555557d432a in audio_close_in (sw=0x7fffbc032bd0) > at /home/petmay01/linaro/qemu-from-laptop/qemu/audio/audio_template.h:375 > #5 0x00005555557d43bc in AUD_close_in (card=0x555556a29a08, sw=0x7fffbc032bd0) > at /home/petmay01/linaro/qemu-from-laptop/qemu/audio/audio_template.h:387 > > qpa_fini_in() basically sets a "done" flag in the PAVoiceIn struct, > and prods the worker thread to make sure it exits before continuing. > Usually this works. Unfortunately if the input thread is in the > middle of actually writing to the buffer then things can go pear > shaped, because the sample buffer itself is freed earlier, by > audio_pcm_hw_gc_in(): > > glue (s->nb_hw_voices_, TYPE) += 1; > glue (audio_pcm_hw_free_resources_ ,TYPE) (hw); > glue (hw->pcm_ops->fini_, TYPE) (hw); > > So we end up freeing hw resources (like the conv_buf) before we > give the pulseaudio backend a chance to actually shut down its > helper thread. > > Does anybody know how this is supposed to work? Is the fix as > simple as just moving the free_resources call below the fini? > > thanks > -- PMM