Possible race conditions when destroying wav_player port

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

If your app is using conf bridge, then the scenario should be safe.
Conf bridge already provides protection (with mutex) on conf ports
accesses, so sound thread(s) and app thread (that does
disconnecting/removing conf ports) should be safely synchronized.

(Btw, while checking the code, I just found a bug in conf_switch.c
regarding accessing port without mutex in its put_frame(), however I
don't really think this is related to this problem).

Regards,
nanang


On Fri, Apr 3, 2009 at 10:10 PM, Ruud Klaver <ruud at ag-projects.com> wrote:
> HI Nanang,
>
> Thanks for the reply.
>
> I was thinking about how to provide protection for it in my application, but
> I'm not sure how. I AM first disconnecting the sound port from all other
> ports on the conference and then removing it from the conference bridge
> before destroying the port. But in the meantime, the sound card thread may
> still be in the file_get_frame() function. There is no means to synchronize
> that it it got out of that function. The only thing I could do is set a
> timer to destroy the port a little later, but that doesn't sound like a real
> solution, as that still does not provide any sort of guarantee.
>
> Ruud Klaver
> AG Projects
>
> On 03 Apr 2009, at 15:56, Nanang Izzuddin wrote:
>
>> Hi,
>>
>> I think it is very possible since wav player is not thread-safe (on
>> purpose), so application needs to make sure that there is no access to
>> wav player before destroying it, e.g: disconnect it from sound port,
>> or remove the wav player port from conference.
>>
>> Regards,
>> nanang
>>
>>
>> On Wed, Apr 1, 2009 at 8:02 PM, Ruud Klaver <ruud at ag-projects.com> wrote:
>>>
>>> Hi,
>>>
>>> I've received reports of the following assertion failure:
>>> ../src/pjmedia/wav_player.c:554:
>>> file_get_frame: Assertion `fport->fmt_tag == PJMEDIA_WAVE_FMT_TAG_ULAW
>>> || fport->fmt_tag == PJMEDIA_WAVE_FMT_TAG_ALAW'
>>> failed
>>>
>>> file_get_frame seems to be called within the context of the soundcard
>>> thread
>>> (which makes sense). What I think is happening is that I'm calling
>>> pjmedia_port_destroy() on the port and pjsip_endpt_release_pool() on the
>>> pool ?containing it while the soundcard thread is in this function.
>>>
>>> My questions are:
>>> 1) Is this possible?
>>> 2) If so, what can I do to prevent this?
>>>
>>> Ruud Klaver
>>> AG Projects
>>>
>>> _______________________________________________
>>> Visit our blog: http://blog.pjsip.org
>>>
>>> pjsip mailing list
>>> pjsip at lists.pjsip.org
>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>
>>
>> _______________________________________________
>> Visit our blog: http://blog.pjsip.org
>>
>> pjsip mailing list
>> pjsip at lists.pjsip.org
>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>
>
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> pjsip at lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>



[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux