Opened 13 years ago

Closed 13 years ago

#1140 closed defect (worksforme)

Crash on disconnecting call with SRTP + ICE (thanks Bogdan Krakowski for the report)

Reported by: nanang Owned by: nanang
Priority: normal Milestone: release-1.8.5
Component: pjmedia Version: trunk
Keywords: Cc:
Backport to 1.x milestone: Backported:

Description

Reported that this occurred on "slow CPU" (iPhone 3G) in "heavy CPU load" and barely reproducible.

The stack when crashing:

0   0x0018bdb4 auth_get_tag_length (auth.c:64)
1   0x001898dc srtp_unprotect (srtp.c:885)
2   0x00135310 srtp_rtp_cb (transport_srtp.c:864)
3   0x0011ce70 ice_on_rx_data (transport_ice.c:1641)
4   0x0014907c stun_on_rx_data (ice_strans.c:1395)
5   0x001404ac on_data_recvfrom (stun_sock.c:815)
6   0x000f08a0 ioqueue_on_read_complete (activesock.c:573)
7   0x000fb4bc ioqueue_dispatch_read_event (ioqueue_common_abs.c:560)
8   0x000fbb7c pj_ioqueue_poll

After investigation, a possible scenario is:

  1. the call is disconnecting, so media deinitialization steps are on progress
  2. an RTP packet is coming and ice_on_rx_data() is about to call SRTP callback rtp_cb in media worker thread
  3. context switch happens, now pjsua_media_channel_deinit() is executed (at least until pjmedia_transport_media_stop()) in signaling worker thread
  4. when the context back to media worker thread, SRTP callback is called after SRTP backend states (or even the SRTP instance itself) have been destroyed

Change History (2)

comment:1 Changed 13 years ago by nanang

(In [3348]) Re #1140, cleaned up the mutex usages in SRTP transport:

  • using mutex in accessing application callback pointers
  • releasing mutex before calling application callbacks to avoid deadlock
  • refine the synchronization of backend/libsrtp states

comment:2 Changed 13 years ago by bennylp

  • Resolution set to worksforme
  • Status changed from new to closed

This would not protect all race condition situations, as there's still one possible scenario where SRTP is being destroyed while a callback is still executing. But nevertheless the fix above should help a bit. Closing the ticket..

Note: See TracTickets for help on using tickets.