PJSIP various fixes

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

 



Hi Robbie,

Thanks for the patches, I've committed the locks-cleanup (with some
modification) and deinit_sip_parser in r4529.. For the mutex, the
EBUSY normally means that we didn't destroy the mutex properly, I've
fixed a couple in r4454 (https://trac.pjsip.org/repos/changeset/4454)
which caused failure to restart in BB10. If you still get EBUSY, the
proper solution should be to find the mutex that wasn't released.

Best regards,
Ming

On Thu, May 30, 2013 at 3:24 PM, Robbie Groenewoudt <robbie at inmote.com> wrote:
> Hi,
>
> We are using PJSIP 2.1 on the Blackberry Z10 nowadays and we had to do
> various fixes. Here's a list of patches, which I hope you will include
> in the next
> release:
>
> mutex_zalloc.patch:
> pj_mutex_create allocates memory from the pool and calls
> pthread_mutex_init(). We had cases where it would return EBUSY error,
> probably because the allocated memory was not zeroed and
> pthread_mutex_init() was thinking it was initializing an existing mutex.
>
> locks-cleanup.patch:
> pjsip_tpmgr_create() creates a mutex and an atomic variable but does not
> clean them up if an error later in the functions occurs.
>
> deinit_sip_parser_call.patch:
> If pjsip_endpt_create() failed for several times, we were hitting
> asserts in pjsip_tel_uri_subsys_init() as it's buffer was full. To
> prevent that, we had to call deinit_sip_parser() for graceful cleanup
> when pjsip_endpt_create() fails.
>
> Robbie Groenewoudt
>
>
>
>
>
> _______________________________________________
> 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