1429085 - Assertion failure: false, at /builds/worker/workspace/build/src/media/webrtc/signaling/src/peerconnection/PeerConnectionMedia.cpp:439

Status: RESOLVED FIXED

(Core :: WebRTC, defect, P2)

Description

[Jason Kratzer [:jkratzer]]

Attachment: trigger.html

Testcase found while fuzzing mozilla-central rev ca379fcca95b.

OS|Linux|0.0.0 Linux 4.4.0-104-generic #127-Ubuntu SMP Mon Dec 11 12:16:42 UTC 2017 x86_64
CPU|amd64|family 6 model 78 stepping 3|1
GPU|||
Crash|SIGSEGV|0x0|14
14|0|libxul.so|mozilla::PeerConnectionMedia::ActivateOrRemoveTransport_s|hg:hg.mozilla.org/mozilla-central:media/webrtc/signaling/src/peerconnection/PeerConnectionMedia.cpp:ca379fcca95b|439|0x18
14|1|libxul.so|mozilla::runnable_args_memfn<RefPtr<mozilla::PeerConnectionMedia>, void (mozilla::PeerConnectionMedia::*)(long unsigned int, long unsigned int, const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, const std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&), long unsigned int, long unsigned int, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >::Run|hg:hg.mozilla.org/mozilla-central:media/mtransport/runnable_utils.h:ca379fcca95b|104|0x13
14|2|libxul.so|nsThread::ProcessNextEvent|hg:hg.mozilla.org/mozilla-central:xpcom/threads/nsThread.cpp:ca379fcca95b|1040|0x15
14|3|libxul.so|NS_ProcessNextEvent|hg:hg.mozilla.org/mozilla-central:xpcom/threads/nsThreadUtils.cpp:ca379fcca95b|517|0x11
14|4|libxul.so|mozilla::net::nsSocketTransportService::Run|hg:hg.mozilla.org/mozilla-central:netwerk/base/nsSocketTransportService2.cpp:ca379fcca95b|961|0x5
14|5|libxul.so|nsThread::ProcessNextEvent|hg:hg.mozilla.org/mozilla-central:xpcom/threads/nsThread.cpp:ca379fcca95b|1040|0x15
14|6|libxul.so|NS_ProcessNextEvent|hg:hg.mozilla.org/mozilla-central:xpcom/threads/nsThreadUtils.cpp:ca379fcca95b|517|0x11
14|7|libxul.so|mozilla::ipc::MessagePumpForNonMainThreads::Run|hg:hg.mozilla.org/mozilla-central:ipc/glue/MessagePump.cpp:ca379fcca95b|334|0xa
14|8|libxul.so|MessageLoop::RunInternal|hg:hg.mozilla.org/mozilla-central:ipc/chromium/src/base/message_loop.cc:ca379fcca95b|326|0x17
14|9|libxul.so|MessageLoop::Run|hg:hg.mozilla.org/mozilla-central:ipc/chromium/src/base/message_loop.cc:ca379fcca95b|319|0x8
14|10|libxul.so|nsThread::ThreadFunc|hg:hg.mozilla.org/mozilla-central:xpcom/threads/nsThread.cpp:ca379fcca95b|423|0x8
14|11|libnspr4.so|_pt_root|hg:hg.mozilla.org/mozilla-central:nsprpub/pr/src/pthreads/ptthread.c:ca379fcca95b|201|0x7
14|12|libpthread-2.23.so||||0x76ba
14|13|libc-2.23.so||||0x1073dd

Comment 1

[Nils Ohlmeier [:drno]]

Looks like an ICE restart problem.

@mjf: can you have a look at this please?

Comment 2

[Michael Froman [:mjf]]

Jason, do you have any special prefs set when running this attachment?

Comment 3

[Jason Kratzer [:jkratzer]]

Attachment: prefs.js

Yes.  Please try these prefs.

Comment 4

[Michael Froman [:mjf]]

Attachment: Bug 1429085 - only initiate ice restart in PeerConnectionMedia if jsep create offer/answer succeeds.

Separate setting up the ice credentials for ice restart from the actual
restart call into PeerConnectionMedia.  This allows waiting until after
the call to JsepSessionImpl::CreateOffer or JsepSessionImpl::CreateAnswer
succeeds.

Review commit: https://reviewboard.mozilla.org/r/212640/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/212640/

Comment 5

[Michael Froman [:mjf]]

In the test case, the call to o1.createOffer({iceRestart: true}) comes after setLocalDescription was called for a previous CreateOffer.  In this case, we'd actually already kicked off the ICE restart, but the call here[1] to JsepSessionImpl::CreateOffer fails because we're in have-local-offer state.  Since we're in the middle of ICE restart, but not fully (having not called UpdateSignalingState) the following call in the test case to setRemoteDescription fails because there are no valid streams.

I've broken up how we setup the ICE restart into 2 pieces:
1) Setup the new ICE credentials for the restart (so we can generate a proper offer w/ new creds)
2) Kickoff the ICE restart after the call to JsepSessionImpl::CreateOffer succeeds.

Comment 6

[Michael Froman [:mjf]]

For above:
[1] https://dxr.mozilla.org/mozilla-central/rev/d2edd256c3aadb1cea48da0c8f62f725bd53cb76/media/webrtc/signaling/src/peerconnection/PeerConnectionImpl.cpp#1547

Comment 7

[Michael Froman [:mjf]]

Have I mentioned how much I love rr?

Comment 8

[Nils Ohlmeier [:drno]]

Comment on attachment 8942356 [details]
Bug 1429085 - only initiate ice restart in PeerConnectionMedia if jsep create offer/answer succeeds.

https://reviewboard.mozilla.org/r/212640/#review218352

LGTM

Comment 9

[Dorel Luca [:dluca]]

Pushed by [e-mail]
https://hg.mozilla.org/integration/autoland/rev/29006b3597ccb3e279af3aa61045fb14a57d0e56
only initiate ice restart in PeerConnectionMedia if jsep create offer/answer succeeds. r=drno

Comment 10

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/29006b3597cc