peerConnection.close() hangs browser tab
Reported by
djpe...@gmail.com,
Sep 21
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36 Steps to reproduce the problem: This problem occurs occasionally while using internal WebRTC-based Web Meeting solution. One of examples: 1. Two Chrome-based participants (P1 and P2) connected peer-to-peer (ice connected, media flows both directions audio video and datachannel) 2. P2 send new offer to P1 3. P2 closes peer connection (decides to go via SFU) 4. P1 applies offer (signaling: has-remote-offer) 5. P1 realize that P2 disconnected (via different channel) and decide to not proceed with local description 6. After 10 seconds P1 gets iceState=disconnected and immediately close peer connection 7. Chrome Tab freeze on calling js peerConnection.close(); 8. Checked that because has console.log() before this line and after. 9. Only message before close appearing in console. 10. Since Tab is frozen if you type any new command in Dev Console you will get no feedback: js thread is stuck. I'm not sure what exact steps is significant to raise freeze. What is the expected behavior? Chrome tab should not freeze on calling peerConnection.close(). It could be error, but not freeze. What went wrong? Chrome Tab got frozen on calling peerConnection.close(). Did this work before? N/A Does this work in other browsers? Yes Chrome version: 69.0.3497.100 Channel: stable OS Version: OS X 10.13.6 Flash Version: Multiple version of Chrome affected by this issue. I saw it since ~61 version or even earlier. I have collected 2 samples with MAC built-in Activity Monitor. Hope they will help to find the root cause. After tab froze we killed tab process with kill -SIGSERV tab_pid in order to collect crash report of this frozen state: CRASH ID = 412d9552-0e42-4d92-8235-985478d7007a
,
Sep 23
,
Sep 24
As per comment# 1, reporter has provided Crash ID, hence forwarding this issue to Inhouse team for further triaging the issue and adding TE-NeedsTriageFromHYD label to it. Thanks!
,
Sep 25
hbos@: Can you take a look and triage further if necessary?
,
Sep 25
Looks like something has deadlocked the signaling thread.
,
Oct 1
RTCPeerConnection.close() waits for any pending getStats-requests to finish, this means the signaling thread is waiting for any tasks on the network thread. (It does however execute any tasks posted to the signaling thread while waiting, so it is live-locked). It also looks like FrameBuffer::NextFrame is busy waiting for "max_wait_time_ms", which may be "kForever"? Is this the "network thread"? https://cs.chromium.org/chromium/src/third_party/webrtc/video/video_stream_decoder_impl.cc?type=cs&sq=package:chromium&g=0&l=136 What does this mean? I wonder if FrameBuffer::NextFrame ends up waiting forever when the transceivers have already been stopped because we are attempting to Close() the PC. https://cs.chromium.org/chromium/src/third_party/webrtc/pc/peerconnection.cc?sq=package:chromium&dr&g=0&l=3219
,
Oct 1
We could tentatively try to move the WaitForPendingRequests until earlier in PeerConnection::Close(), I don't remember if there was a reason for placing it after stopping the transceiver.
,
Oct 1
Cc people who have touched frame_buffer2.cc
,
Jan 4
We are wondering if there are some updates for this issue. Since this issue affects us, we are also looking forward for fixes, and meanwhile working on possible workarounds. Thanks.
,
Jan 7
Is this possible to reproduce in a simple demo like a codepen? https://codepen.io/pen/ |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by djpe...@gmail.com
, Sep 21