[libnice] multithread g_main_loop_quit ad remove agent
Emanuele Bizzarri
emabiz76 at gmail.com
Mon Jul 14 02:25:24 PDT 2014
Hi Philip,
ok we started working on 0.1.7 plus gstreamer 1.3.90.
Using examples we find an issue on test-parse.
stun_message_validate_buffer_length function set
stun_message_validate_buffer_length_fast return value to var fast_retval.
But fast_retval type is unsigned long and
stun_message_validate_buffer_length_fast return -1
(STUN_MESSAGE_BUFFER_INVALID is -1).
So (fast_retval<=0) will be always false.
We have changed fast_retval type (signed long) and now all seems work
correctly.
But we are still able to crash our application.
Now we are searching a way to get a backtrace.
Some considerations inline.
Il 14/07/2014 09:41, Philip Withnall ha scritto:
> Otherwise you could cause a deadlock by calling a libnice function on
that agent from the callback, I think. Olivier knows more about that
design decision than me though.
Deadlock shold not happen because if I use a libnice function inside the
callback the mutex will be acquired twice from the same thread and
released twice at the end of the callback.
Different might be the case if there is an other internal thread that
use the same mutex.
>
> If you want to destroy the user_data in a thread other than the one
> running the main context you passed to nice_agent_attach_recv(), you
> need to either:
> • implement your own locking on the user_data, or
> • (preferably) make it reference counted, and ensure the reference
> counting functions are thread safe.
Our application is not based on glib, so we are required to destroy
user_data from another thread.
More information about the nice
mailing list