Able to reproduce the issue on Windows 10, Ubuntu 14.04 and Mac 10.12.6 using chrome stable version #61.0.3163.100 and latest canary #63.0.3226.0.

Bisect Information:
=====================
Good build: 61.0.3129.0	 Revision(478840)
Bad Build : 61.0.3130.0	 Revision(479232)

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/9fc3341ca5afc14bc3ab776a0718e53cce1d49a1..7ff812ea2691302e2307ff0e5c645cce989d420b

From the above change log suspecting below change
Review URL: https://codereview.chromium.org/2902733003

hbos@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Note: Adding label ReleaseBlock-Stable as it seems to be a recent regression. Please feel free to remove the same if not appropriate.

Thanks...!!

Oh snap, I'll take a look on Monday!

Here's a jsfiddle: https://jsfiddle.net/xn4fpywr

Seems to be related to the video and audio tracks having the same ID.

[1:20:0929/144137.577861:FATAL:webrtc_media_stream_track_adapter_map.cc(23)] Check failed: map_->main_thread_->BelongsToCurrentThread(). 
#0 0x7f88c1ab805d base::debug::StackTrace::StackTrace()
#1 0x7f88c1ab642c base::debug::StackTrace::StackTrace()
#2 0x7f88c1b4792a logging::LogMessage::~LogMessage()
#3 0x7f88bcc9feaa content::WebRtcMediaStreamTrackAdapterMap::AdapterRef::~AdapterRef()
#4 0x7f88bcc8ca14 std::__1::pair<>::~pair()
#5 0x7f88bcc885b6 content::WebRtcMediaStreamAdapter::GetAdapterRefMapFromWebRtcStream()
#6 0x7f88bcc8a6e6 content::RemoteWebRtcMediaStreamAdapter::RemoteWebRtcMediaStreamAdapter()
#7 0x7f88bcc8c8ef _ZN4base10MakeUniqueIN7content30RemoteWebRtcMediaStreamAdapterEJ13scoped_refptrINS_22SingleThreadTaskRunnerEES3_INS1_32WebRtcMediaStreamTrackAdapterMapEES3_IN6webrtc20MediaStreamInterfaceEEEEEDTclsr3stdE11make_uniqueIT_Espclsr3stdE7forwardIT0_Efp_EEEDpOSC_
#8 0x7f88bcc8759f content::WebRtcMediaStreamAdapter::CreateRemoteStreamAdapter()
#9 0x7f88bcc91a85 content::WebRtcMediaStreamAdapterMap::GetOrCreateRemoteStreamAdapter()
#10 0x7f88bcbfb0d0 content::RTCPeerConnectionHandler::Observer::OnAddStream()
#11 0x7f88bdc9e7f9 webrtc::PeerConnection::SetRemoteDescription()

It makes sense my change would have caused this, but I would have thought https://chromium-review.googlesource.com/c/chromium/src/+/666923 should fix it. That is not the case, its still crashing on tip of tree. I need to investigate further.

This must not be a common use case considering how long it took until it was detected, but it would be nice to fix this for 62 stable, if possible to merge - there as been a lot of changes in these parts of the code recently.

Nevermind, I have fixed allowing same IDs for streams and tracks removed and re-added, but the thread check is a different problem and audio and video tracks having the same ID is something different too. Is that even allowed?

I can't find anything that disallows it, but may be a good question for the mailing list.

Related issue: https://bugs.chromium.org/p/webrtc/issues/detail?id=5625

Here's a tweak to that fiddle so you have to press "Run" before it crashes: https://jsfiddle.net/1wkzhszp/

There are AdapterRefs created for track adapters on the webrtc signaling threads. These need to be destroyed on the main thread, which they normally are because the RemoteWebRtcMediaStreamAdapter that takes ownership of the AdapterRefs is destroyed on the main thread.

The problem is this line:
https://cs.chromium.org/chromium/src/content/renderer/media/webrtc/webrtc_media_stream_adapter.cc?type=cs&sq=package:chromium&l=55

There is an ID -> AdapterRef map assuming IDs are unique. The second "insert" does not insert the element because there is already a mapping, and the AdapterRef we tried to insert is instead destroyed here, on the webrtc signaling thread.

1. Audio and video tracks have different SSRCs and IDs:
https://jsfiddle.net/n5e0e6oc/

This works as expected. Promise is resolved.

2. Audio and video have different IDs but the same SSRC:
https://jsfiddle.net/v117d6sz/

The promise is resolved, but it shouldn't be. Tracks shouldn't be able to have the same SSRC.

3. Audio and video have different SSRCs but the same ID:
https://jsfiddle.net/n0xbs31k/

Whether this should be resolved or rejected is debatable, but it crashes. It shouldn't.

4. Combination of 2+3: Audio and video have same SSRC and ID:
https://jsfiddle.net/jkdewtd3/

This crashes for the same reason as 3). It should be rejected for the same reason as 2).

The bug is reported with case 4). oshiro.hugo@gmail.com: See comment #11, you're doing something wrong by having the same SSRC for both tracks. Of course we still need to fix this bug so it doesn't crash, but FYI when all bugs are fixed your SDP will be rejected.

WRT 2) I filed webrtc repo issue https://crbug.com/webrtc/8328.
WRT 3) I will try to fix this tomorrow, gotta run.

Thanks for the effort and clarifications, hbos@chromium.org. I'll solve things here on my side.

With https://chromium-review.googlesource.com/c/chromium/src/+/700263 I fixed the problem in the chromium layers, but it turns out that there are assumptions in the webrtc layer too. For example, FindReceiverForTrack looks up receiver by track ID, which in this case is not unique.

With my CL it still crashes when I run 3) because it gets the wrong receiver from the webrtc layer.

I think (at least for now) the appropriate action is to reject the promise. I filed: https://crbug.com/webrtc/8339

hbos@ Gentle ping! Since this issue is marked as RB-Stable for M-62 could you please let us know is there any latest update available on this issue?

Thanks!

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/db00702e9e2ed80c69ddbfe4a234eefacdc10e35

commit db00702e9e2ed80c69ddbfe4a234eefacdc10e35
Author: Henrik Boström <hbos@chromium.org>
Date: Mon Oct 09 17:35:22 2017

Handle streams containing multiple tracks with the same ID.

Using WebMediaStreamTrack::UniqueId() and
webrtc::MediaStreamTrackInterface* as unique identifiers for tracks,
instead of assuming their string ID is unique.

A similar fix was previously made for the
WebRtcMediaStream[Track]AdapterMaps (mapping *all* streams and *all*
tracks), but the assumption about track IDs being unique was still made
on a per-stream basis.

This CL removes that assumption and adds test coverage.

Bug: 769470
Change-Id: If2c13ea44856e4d25fb8579e4dee9eb595d29b9f
Reviewed-on: https://chromium-review.googlesource.com/700263
Reviewed-by: Guido Urdaneta <guidou@chromium.org>
Commit-Queue: Henrik Boström <hbos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#507400}
[modify] https://crrev.com/db00702e9e2ed80c69ddbfe4a234eefacdc10e35/content/renderer/media/media_stream_video_track.cc
[modify] https://crrev.com/db00702e9e2ed80c69ddbfe4a234eefacdc10e35/content/renderer/media/media_stream_video_track.h
[modify] https://crrev.com/db00702e9e2ed80c69ddbfe4a234eefacdc10e35/content/renderer/media/webrtc/webrtc_media_stream_adapter.cc
[modify] https://crrev.com/db00702e9e2ed80c69ddbfe4a234eefacdc10e35/content/renderer/media/webrtc/webrtc_media_stream_adapter.h
[modify] https://crrev.com/db00702e9e2ed80c69ddbfe4a234eefacdc10e35/content/renderer/media/webrtc/webrtc_media_stream_adapter_unittest.cc

hbos@, thank you for the fix. Unfortunately we don't have latest canary with the above fix (Due to crbug/773185) to verify, however we will do it on tonight's Canary.

Please plan to request a merge to M62 (Branch: 3202)if you think the fix is really critical.

Unfortunately, the above CL only fixes half of the problem. There's another assumption in third_party/webrtc, see https://crbug.com/webrtc/8339. It will still crash but the stack trace will be different.

I don't think this is a release blocker or that we should merge (even when it's fully fixed), lowering the priority. I'll take another look when I have time.