media/webrtc/signaling/src/peerconnection/PeerConnectionCtx.cpp:106 CSFLogDebug(logTag, "%s - %d : %d", __FUNCTION__, state, mSipccState); media/webrtc/signaling/src/peerconnection/PeerConnectionCtx.h:51 void ChangeSipccState(PeerConnectionImpl::SipccState aState) { mSipccState = aState; } Tested with m-c changeset: 111684:e19e170d2f6d

If i see the call-stack .. this happens during Initialize of PeerConnection and Sipcc. The race is against peerconnectionimpl's state is with respect to kIdle vs kStarting and changing it to kStarted. since we handle both the states under the same if() in OnDeviceEvent() in PeerConnectionCtx.cpp, the race shouldn't affect the state of peer-connection...

Is there a way to setup my Mac Env to reproduce the race ....

I have tried to run TSan on MacOS but it didn't work properly. The best is to use a VM with a 32bit Ubuntu. In case you have trouble to setup TSan - am working on a small how-to which I hopefully can put online tomorrow.

Thanks Christoph .. I shall wait on TSan write up. In the meanwhile let me go through the code flow to do some offline analysis.

Suhas: https://developer.mozilla.org/en-US/docs/Thread_Sanitizer not finished yet but should provide you with the necessary steps to reproduce this condition. If you run into trouble ping me on IRC.

(In reply to Suhas from comment #1) > If i see the call-stack .. this happens during Initialize of PeerConnection > and Sipcc. The race is against peerconnectionimpl's state is with respect > to kIdle vs kStarting and changing it to kStarted. > > since we handle both the states under the same if() in OnDeviceEvent() in > PeerConnectionCtx.cpp, the race shouldn't affect the state of > peer-connection... Sure it can (depending on the compiler, at least in theory): in kIdle it tests against kStarting and fails, then (on another thread) kIdle changes to kStarting, and then it tests against kIdle, which also (now) fails. Now, most compilers will not reload the state for each test, but they might for pure-debug builds.

You can avoid that issue by loading it once to a local var. There's still a race against the debug, but the debug isn't important here (you should comment the debug, stating we're ignoring a possible data race on printing the state).

This fell off radar; assigning to Suhas.