825212 - ice_peer_ctx accessed after destruction

Status: RESOLVED DUPLICATE of bug 824263

(Core :: WebRTC: Networking, defect, P1)

Description

[Eric Rescorla (:ekr)]

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
[Switching to process 22675 thread 0x3813]
0x000000010466a3c5 in nr_ice_peer_ctx_find_component (pctx=0x10f3fc90c, str=0x11435320c, component_id=1, compp=0x10bd01760) at ice_peer_ctx.c:454
454           if(pstr->local_stream==str)
Current language:  auto; currently minimal
(gdb) where
#0  0x000000010466a3c5 in nr_ice_peer_ctx_find_component (pctx=0x10f3fc90c, str=0x11435320c, component_id=1, compp=0x10bd01760) at ice_peer_ctx.c:454
#1  0x000000010466a4ab in nr_ice_peer_ctx_deliver_packet_maybe (pctx=0x10f3fc90c, comp=0x1267d647c, source_addr=0x10bd018d8, data=0x10bd01a40 "\024??", len=91) at ice_peer_ctx.c:488
#2  0x00000001046654a2 in nr_ice_ctx_deliver_packet (ctx=0x113fa235c, comp=0x1267d647c, source_addr=0x10bd018d8, data=0x10bd01a40 "\024??", len=91) at ice_ctx.c:462
#3  0x000000010466ad31 in nr_ice_socket_readable_cb (s=0x10ef92100, how=0, cb_arg=0x12254b3ac) at ice_socket.c:162
#4  0x00000001046a053d in mozilla::NrSocket::fire_callback (this=0x10ef92100, how=0) at nr_socket_prsock.cpp:190
#5  0x00000001046a0473 in mozilla::NrSocket::OnSocketReady (this=0x10ef92100, fd=0x100510430, outflags=1) at nr_socket_prsock.cpp:124
#6  0x00000001014a2c16 in nsSocketTransportService::DoPollIteration (this=0x10051ade0, wait=false) at /Users/Adam/devel/mozilla/mozilla-inbound/netwerk/base/src/nsSocketTransportService2.cpp:784
#7  0x00000001014a25e2 in nsSocketTransportService::Run (this=0x10051ade0) at /Users/Adam/devel/mozilla/mozilla-inbound/netwerk/base/src/nsSocketTransportService2.cpp:641
#8  0x00000001014a301c in non-virtual thunk to nsSocketTransportService::Run() () at /Users/Adam/devel/mozilla/mozilla-inbound/netwerk/base/src/nsSocketTransportService2.cpp:707
#9  0x0000000103a4e8d4 in nsThread::ProcessNextEvent (this=0x100538eb0, mayWait=true, result=0x10bd03dee) at /Users/Adam/devel/mozilla/mozilla-inbound/xpcom/threads/nsThread.cpp:627
#10 0x00000001039b72df in NS_ProcessNextEvent_P (thread=0x100538eb0, mayWait=true) at nsThreadUtils.cpp:237
#11 0x0000000103a4d3a7 in nsThread::ThreadFunc (arg=0x100538eb0) at /Users/Adam/devel/mozilla/mozilla-inbound/xpcom/threads/nsThread.cpp:265
#12 0x0000000100638583 in _pt_root (arg=0x100563790) at /Users/Adam/devel/mozilla/mozilla-inbound/nsprpub/pr/src/pthreads/ptthread.c:156
#13 0x00007fff85fcf742 in _pthread_start ()
#14 0x00007fff85fbc181 in thread_start ()
(gdb)
(gdb) p str
$2 = (nr_ice_media_stream *) 0x11435320c
(gdb) p pstr
$3 = (nr_ice_media_stream *) 0x5a5a5a5a5a5a5a5a
(gdb)

Online diagnosis with abr indicates that the problem is that the peer_ctx does not remove itself when it is destroyed. The following should fix it:


ekr: At the end of nr_ice_peer_ctx_destroy_cb add
[3:02pm] ekr: (before the free)
[3:04pm] abr: I think something must have been lost inthe paste
[3:04pm] ekr: add STAILQ_REMOVE(&pctx->ctx->peers, pctx, nr_ice_peer_ctx, entry);
[3:04pm] ekr: That will remove the peer ctx

Comment 1

[Adam Roach [:abr]]

FWIW, with this one-line fix, I have not seen this bug arise again in the mochi tests. It's a little hard to be 100% certain that it's gone, since the crashes from Bug 824851 and Bug 824359 dominate the mochi test runs.

Comment 2

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

This looks to me like a dup of Bug 824263. The one-line fix makes sense to me, as 824263 is seeing freed memory access in nr_ice_ctx_deliver_packet() which is operating on all siblings in the peers list. Thanks for the fix! I'll test and add it to 824263.

Comment 3

[Eric Rescorla (:ekr)]

thanks.