Custom Query (2195 matches)

It is reported that a deadlock might occur when handling IP change / pjsua_handle_ip_change() is called.

Scenario:

1. [MainThread] Transport is being shutdown e.g: by pjsua_handle_ip_change() -> pjsip_transport_shutdown()
   • at the start it will lock the transport (tp->lock)
2. [pjsua_0] Incoming new INVITE message
   • lock pjsua on pjsua_call_on_incoming()
   • try to lock transport on tsx_update_transport() -> pjsip_transport_add_state_listener()
3. [MainThread]
   • try to lock pjsua_acc_on_tp_state_changed() >> deadlock

The issue is caused by two things:

• Due to #2097, pjmedia_transport_media_stop() for UDP transport will call pj_ioqueue_post_completion(). This will trigger on_read_complete() callback, i.e. on_rx_rtp() which will call pj_ioqueue_recvfrom(). So the read operations never really stop.
• Ioqueue itself never checks when an op_key is already in the list. Thus, when the media transport is restarted, it will call pj_ioqueue_recvfrom() again. Calling recv() with the same op_key will cause the list to be in a bad state (i.e. the element's next and prev pointers will lose track of its neighbours, hence causing the list to be uniterable). Thus, when later calling pjmedia_transport_detach(), and UDP media transport calling pj_ioqueue_post_completion() for its pending write_op, the function may get stuck when iterating the read list.

Currently libRegisterThread() is not thread-safe. The access to the thread descriptor map needs to be protected in order to avoid data race.