Chrome M57 keeps crashing when running WebRTC with Chrome M56
Reported by
maojie0...@gmail.com,
Apr 7 2017
|
|||||||||||
Issue descriptionWhat steps will reproduce the problem? 1. Open https://webdemo.agora.io/videocall/ and enter a room name using Chrome M57 2. Open https://webdemo.agora.io/videocall/ and enter the previous room name using Chrome M56 3. After a while, Chrome M57 crashed. What is the expected result? Chrome M57 is not crashing. What do you see instead? Chrome M57 crashes. What version of the product are you using? On what operating system? Google Chrome 57.0.2987.133 (Official Build) (64-bit) Revision ec33cd0c06881d919ac0de419d829ad914e0be8f-refs/branch-heads/2987@{#887} OS Mac OS X JavaScript V8 5.7.492.71 Please provide any additional information below. I've build the same version of Chromium, but I can't reproduce the crash, not sure if there's any difference between the official build and the developer build. My Chromium build version: Chromium 57.0.2987.133 (Developer Build) (64-bit) Revision 8a67263f2d4e0fcbf1675e08b7e24672046463d2 OS Mac OS X JavaScript V8 5.7.492.71
,
Apr 7 2017
,
Apr 7 2017
,
Apr 10 2017
Can you provide us with a crash ID? Open chrome://crashes and find the entry that matches the time of the crash. (In the release build.)
,
Apr 11 2017
Crash ID 0ea2c3d3-8574-45a7-88fd-ae3386f2b557 (Server ID: a2c2b19640000000)
,
Apr 17 2017
Is there any update about this issue?
,
Apr 18 2017
,
Apr 18 2017
Crash is occurring in VCMFrameBuffer::GetNaluInfos(). Most relevant stack frames: (Google Chrome Framework -memory:1784 ) webrtc::VCMSessionInfo::GetNaluInfos() const (Google Chrome Framework -frame_buffer.cc:70 ) webrtc::VCMFrameBuffer::GetNaluInfos() const (Google Chrome Framework -decoding_state.cc:235 ) webrtc::VCMDecodingState::ContinuousFrame(webrtc::VCMFrameBuffer const*) const (Google Chrome Framework -jitter_buffer.cc:820 ) webrtc::VCMJitterBuffer::IsContinuous(webrtc::VCMFrameBuffer const&) const (Google Chrome Framework -jitter_buffer.cc:738 ) webrtc::VCMJitterBuffer::InsertPacket(webrtc::VCMPacket const&, bool*) (Google Chrome Framework -receiver.cc:110 ) webrtc::VCMReceiver::InsertPacket(webrtc::VCMPacket const&) (Google Chrome Framework -video_receiver.cc:425 ) webrtc::vcm::VideoReceiver::IncomingPacket(unsigned char const*, unsigned long, webrtc::WebRtcRTPHeader const&) (Google Chrome Framework -rtp_stream_receiver.cc:295 ) webrtc::RtpStreamReceiver::OnReceivedPayloadData(unsigned char const*, unsigned long, webrtc::WebRtcRTPHeader const*) (Google Chrome Framework -rtp_receiver_video.cc:103 ) webrtc::RTPReceiverVideo::ParseRtpPacket(webrtc::WebRtcRTPHeader*, webrtc::PayloadUnion const&, bool, unsigned char const*, unsigned long, long long, bool) (Google Chrome Framework -rtp_receiver_impl.cc:177 ) webrtc::RtpReceiverImpl::IncomingRtpPacket(webrtc::RTPHeader const&, unsigned char const*, unsigned long, webrtc::PayloadUnion, bool) (Google Chrome Framework -rtp_stream_receiver.cc:456 ) webrtc::RtpStreamReceiver::OnRecoveredPacket(unsigned char const*, unsigned long) (Google Chrome Framework -ulpfec_receiver_impl.cc:236 ) webrtc::UlpfecReceiverImpl::ProcessReceivedFec() (Google Chrome Framework -rtp_stream_receiver.cc:474 ) webrtc::RtpStreamReceiver::ParseAndHandleEncapsulatingHeader(unsigned char const*, unsigned long, webrtc::RTPHeader const&) (Google Chrome Framework -rtp_stream_receiver.cc:446 ) webrtc::RtpStreamReceiver::DeliverRtp(unsigned char const*, unsigned long, webrtc::PacketTime const&) (Google Chrome Framework -call.cc:1143 ) webrtc::internal::Call::DeliverRtp(webrtc::MediaType, unsigned char const*, unsigned long, webrtc::PacketTime const&) (Google Chrome Framework -webrtcvideoengine2.cc:1381 ) cricket::WebRtcVideoChannel2::OnPacketReceived(rtc::CopyOnWriteBuffer*, rtc::PacketTime const&) (Google Chrome Framework -channel.cc:837 ) cricket::BaseChannel::OnPacketReceived(bool, rtc::CopyOnWriteBuffer const&, rtc::PacketTime const&) Changing component to Video.
,
Apr 19 2017
This is unfortunate, but this code is being replaced in M58 which is soon stable, so I doubt it's worth fixing. Philip/Rasmus, do you know of any changes in M57 which may have caused this? AFAIK we should never be sending ULPFEC with H.264, so it looks incorrect that this code path can even be reached.
,
Apr 19 2017
On the top of my head, I'm not aware of any changes that might have caused ULPFEC packets to be sent for H264. With NACK, we should not be sending H264+ULPFEC, but without NACK, we can do it: https://cs.chromium.org/chromium/src/third_party/webrtc/video/video_send_stream_tests.cc?l=506 The linked webapp seems to not disable NACK, however: a=rtpmap:100 H264/90000 a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli a=rtcp-fb:100 goog-remb a=rtcp-fb:100 transport-cc
,
Apr 19 2017
I know the performance issue caused by enabling the H264 with ULPFEC, but this webapp is using VP8 under the communication mode, I have removed the H264 line in the answer SDP. Not sure why the crashing only happens in the official build of Chrome M57.
,
Apr 26 2017
,
Oct 24
|
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by maojie0...@gmail.com
, Apr 7 2017