Bug 169938 – RTCPeerConnection is crashing if no backend is created

• Component: WebCore Misc.
• Status: RESOLVED FIXED

[youenn fablet]

RTCPeerConnection is crashing if no backend is created.

[youenn fablet]

Created attachment 305053 [details]
Patch

[youenn fablet]

Might be related to rdar://30796880

[Geoffrey Garen]

Comment on attachment 305053 [details]
Patch

I see a lot of methods that use m_backend and don't check for RTCSignalingState::Closed. How do we know they're OK?

[youenn fablet]

(In reply to Geoffrey Garen from comment #3)
> Comment on attachment 305053 [details]
> Patch
> 
> I see a lot of methods that use m_backend and don't check for
> RTCSignalingState::Closed. How do we know they're OK?

Since RTCPeerConnection is a 
Once created,

[youenn fablet]

(In reply to youenn fablet from comment #4)
> (In reply to Geoffrey Garen from comment #3)
> > Comment on attachment 305053 [details]
> > Patch
> > 
> > I see a lot of methods that use m_backend and don't check for
> > RTCSignalingState::Closed. How do we know they're OK?
> 
> Since RTCPeerConnection is a 
> Once created,

Since RTCPeerConnection is a JS built-in, once the C++ wrapper is created, initializeWith will be called and will return an exception.
But the C++ object remains an active DOM object that remains to be stopped.
Setting the state to closed allows RTCPeerConnection::close to be a no-op.

But really, we should solve the real issue, which is that RTCPeerConnection is exposed while isLibWebRTCAvailable returns false.
Once done, m_backend should be made a uniqueref.

[WebKit Commit Bot]

Comment on attachment 305053 [details]
Patch

Clearing flags on attachment: 305053

Committed r214262: <http://trac.webkit.org/changeset/214262>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.