Heap corruption in "pjmedia/pasound.c" thread

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

 



Hi Alain,

IIRC, there was also another consideration with 'thread unregistering'
solution, let's see this scenario:
1. There is a case that the thread issuing callbacks is switched when
headset is plugged-unplugged, e.g: on MacOS platform.
2. Current sound device session headset is unplugged, so the
'unplugged' thread is registered.
3. Then headset is plugged in, so now the 'plugged' thread is also
registered, both threads are sharing the same TLS data address.
4. Sound device session is stopped, the 'plugged' thread is
unregistered, TLS data is freed, but 'unplugged' thread remains
registered (doesn't it?).
5. Headset unplugged.
6. New sound device session is started and callback threads are
reused, the callbacks will see that the 'unplugged' thread has been
registered and where it actually refers to invalid TLS data address!

This scenario should be covered by changeset 2426 (of ticket #701).

Regards,
nanang


On Thu, Jan 22, 2009 at 4:52 PM, Alain Totouom <alain.totouom at gmx.de> wrote:
> Hi Benny,
>
> Benny Prijono wrote:
>> we considered the thread_unregister() approach for the fix, but then decided
>> that the flag approach should work just as good if not better, and easier to
>> do since we don't need to implement thread_unregister() for all platforms.
>> If you have any means to test this I would truly appreciate it.
>>
>
> I'll still argue for the *thread_unregister* approach which works well on ALL platforms where the macro *PJ_HAS_THREAD* is defined. Adjusting the patch to check if that macro is set should remove the burden of implementing that function for all platforms!
>
> The behavior implemented in r2426 (ticket #701) was the one used before r1893 and was changed due to ticket #516.
> We had to implement it since after the support for idling the sound device was added, we had to deal with rather difficult to reproduce crashes due to the sound thread sometime referencing to a freed, 'used' but not reseted TLS slot index.
> And now let me play the marketing guy ;o)
> It costs nothing to to reset the TLS structure (slot index) when no more needed but the thread is to be re-used ;o)
>
> Over to you ;o)
> Cheers,
> Alain
>
>
> --
>                            ""
>                          (o)(o)
>                  ___o00o__(__)__o00o_____
> 1024D/A9F85A52 2000-01-18 Dipl.-Ing. Alain Totouom <totouom at gmx.de>
> PGP Fingerprint   DA18 0DF2 FBD2 5F67 0656 452D E3A2 7531 A9F8 5A52
>
> _______________________________________________
> 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