Null deref in mozilla::TransportLayerIce::IcePacketReceived(mozilla::NrIceMediaStream*, int, unsigned char const*, int) [sigslot.h : 2477 + 0x10] https://tbpl.mozilla.org/php/getParsedLog.php?id=18385937&tree=Try Not sure if this is a dup. This try run includes roc's canplaythrough patch (bug 814718), both of jib's patches and ekr's patch that are pending. Bug 824263, bug 824851, ekr's async cancellation patch (forget the number), and a patch to emable all webrtc mochitests.

It's really hard to assess this without the details of the state of these structures. What can we do to get that?

Crash reason: EXC_BAD_ACCESS / 0x0000000d Crash address: 0x0 Thread 4 (crashed) 0 XUL!mozilla::TransportLayerIce::IcePacketReceived(mozilla::NrIceMediaStream*, int, unsigned char const*, int) [sigslot.h : 2477 + 0x10] rbx = 0x0000000000000052 r12 = 0x0000000138da2610 r13 = 0x0000000138da2680 r14 = 0x0000000138da2680 r15 = 0x000000010646ecd0 rip = 0x0000000102f57fd3 rsp = 0x000000010646e7f0 rbp = 0x000000010646e9c0 Found by: given as instruction pointer in context 1 XUL!mozilla::NrIceCtx::msg_recvd(void*, nr_ice_peer_ctx_*, nr_ice_media_stream_*, int, unsigned char*, int) [sigslot.h : 2544 + 0x1b] rbx = 0x0000000000000052 r12 = 0x0000000000000052 r13 = 0x000000010646ecd0 r14 = 0x0000000138da2b90 r15 = 0x0000000000000001 rip = 0x0000000102f4d843 rsp = 0x000000010646e9d0 rbp = 0x000000010646ea20 Found by: call frame info 2 XUL!nr_ice_peer_ctx_deliver_packet_maybe [ice_peer_ctx.c : 515 + 0x22] rbx = 0x000000010646eb68 r12 = 0x00000001006948fc r13 = 0x000000010c510f2c r14 = 0x0000000000000000 r15 = 0x0000000145f111dc rip = 0x0000000102f3c7b1 rsp = 0x000000010646ea30 rbp = 0x000000010646ea70 Found by: call frame info 3 XUL!nr_ice_ctx_deliver_packet [ice_ctx.c : 462 + 0x13] rbx = 0x00000001006948fc r12 = 0x000000010c510f2c r13 = 0x000000010646eb68 r14 = 0x0000000000000052 r15 = 0x000000010646ecd0 rip = 0x0000000102f39e5d rsp = 0x000000010646ea80 rbp = 0x000000010646eab0 Found by: call frame info 4 XUL!nr_ice_socket_readable_cb [ice_socket.c : 162 + 0x1d] rbx = 0x0000000129cb109c r12 = 0x0000000104414328 r13 = 0x0000000000000052 r14 = 0x0000000129cb109c r15 = 0x0000000104414328 rip = 0x0000000102f3cc02 rsp = 0x000000010646eac0 rbp = 0x0000000106470d00 Found by: call frame info 5 XUL!mozilla::NrSocket::OnSocketReady(PRFileDesc*, short) [nr_socket_prsock.cpp : 190 + 0xd] rbx = 0x000000012bd9cf90 r12 = 0x000000010014a480 r13 = 0x0000000000000000 r14 = 0x0000000000000001 r15 = 0x0000000000000004 rip = 0x0000000102f54911 rsp = 0x0000000106470d10 rbp = 0x0000000106470d20 Found by: call frame info 6 XUL!nsSocketTransportService::DoPollIteration(bool) [nsSocketTransportService2.cpp : 802 + 0xe] rbx = 0x0000000000000070 r12 = 0x000000010014a480 r13 = 0x0000000000000000 r14 = 0x0000000000000050

We believe this is fixed. jsmith --whimboo is on vacation. Can you retest this?

I'm a bit puzzled how to go about testing this other than seeing if a stack shows up in CI again by our tree managers. Isn't it enough to just not see the stack while these tests run in CI? And make sure there's no stack in crash stats that matches this bug? Henrik - What do you think? Unless you think there's an explicit way to verify this other than "make sure the crash stack doesn't show up in CI."

Got my answer with Clint - we can close this bug for the following reasons: 1. No info on orange factor - http://brasstacks.mozilla.com/orangefactor/?display=Bug&tree=trunk&startday=2012-12-03&endday=2013-02-22&bugid=825764 2. Matt ran the tests on a local ASAN build recently and did not see any crashes after running them a few times 3. TBPL isn't yelling loud log messages on this bug If we end up finding this crash again, we can always reopen. But I'm inclined to close based on the above items.