825764 - Intermittent crash in /tests/dom/media/tests/mochitest/test_peerConnection_basicAudioVideo.html | null deref in [@ mozilla::TransportLayerIce::IcePacketReceived()]

Status: RESOLVED WORKSFORME

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

Description

[Randell Jesup [:jesup] (needinfo me)]

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.

Comment 1

[Eric Rescorla (:ekr)]

It's really hard to assess this without the details of the state of these structures.

What can we do to get that?

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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

Comment 3

[Maire Reavy [:mreavy]]

We believe this is fixed. 

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

Comment 4

[Jason Smith [:jsmith]]

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."

Comment 5

[Jason Smith [:jsmith]]

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.