1252488 - Firefox crash during Hello session

Status: RESOLVED DUPLICATE of bug 1263384

(Core :: WebRTC: Audio/Video, defect, P1)

Description

[Ian Bicking (:ianbicking)]

During a Hello session Firefox crashed.  Crash report: https://crash-stats.mozilla.org/report/index/58eacedd-0141-4862-bea1-c9b292160301

The particular moment happened when I hit ⌘U to view source on the tab I was sharing (though I had done so already earlier in the session)

Comment 1

[Ian Bicking (:ianbicking)]

Another crash ID that is probably similar: fc052683-13d1-432d-9764-c9bec2160301

Room: https://loop-webapp-dev.stage.mozaws.net/lz-PTOryDz8#bJQCtm-EiiAmvMGTas0e0Q

Comment 2

[Mark Banner (:standard8)]

Looks like something in the VP8 encoder:

0 	libsystem_platform.dylib 	libsystem_platform.dylib@0x5c49 	
1 	XUL 	copy_and_extend_plane 	/Developer/SDKs/MacOSX10.7.sdk/usr/include/secure/_string.h:83
2 	XUL 	vp8_copy_and_extend_frame 	media/libvpx/vp8/common/extend.c
3 	XUL 	vp8_lookahead_push 	media/libvpx/vp8/encoder/lookahead.c
4 	XUL 	vp8_receive_raw_frame 	media/libvpx/vp8/encoder/onyx_if.c
5 	XUL 	vp8e_encode 	media/libvpx/vp8/vp8_cx_iface.c
6 	XUL 	vpx_codec_encode 	media/libvpx/vpx/src/vpx_encoder.c
7 	XUL 	webrtc::VP8EncoderImpl::Encode(webrtc::I420VideoFrame const&, webrtc::CodecSpecificInfo const*, std::vector<webrtc::VideoFrameType, std::allocator<webrtc::VideoFrameType> > const*) 	media/webrtc/trunk/webrtc/modules/video_coding/codecs/vp8/vp8_impl.cc
8 	XUL 	webrtc::VCMGenericEncoder::Encode(webrtc::I420VideoFrame const&, webrtc::CodecSpecificInfo const*, std::vector<webrtc::FrameType, std::allocator<webrtc::FrameType> > const&) 	media/webrtc/trunk/webrtc/modules/video_coding/main/source/generic_encoder.cc
9 	XUL 	webrtc::vcm::VideoSender::AddVideoFrame(webrtc::I420VideoFrame const&, webrtc::VideoContentMetrics const*, webrtc::CodecSpecificInfo const*) 	media/webrtc/trunk/webrtc/modules/video_coding/main/source/video_sender.cc
10 	XUL 	webrtc::ViEEncoder::DeliverFrame(int, webrtc::I420VideoFrame*, std::vector<unsigned int, std::allocator<unsigned int> > const&) 	media/webrtc/trunk/webrtc/video_engine/vie_encoder.cc
11 	XUL 	webrtc::ViEFrameProviderBase::DeliverFrame(webrtc::I420VideoFrame*, std::vector<unsigned int, std::allocator<unsigned int> > const&) 	media/webrtc/trunk/webrtc/video_engine/vie_frame_provider_base.cc
12 	XUL 	webrtc::ViECapturer::DeliverI420Frame(webrtc::I420VideoFrame*) 	media/webrtc/trunk/webrtc/video_engine/vie_capturer.cc
13 	XUL 	webrtc::ViECapturer::ViECaptureProcess() 	media/webrtc/trunk/webrtc/video_engine/vie_capturer.cc
14 	XUL 	webrtc::ThreadPosix::StartThread(void*) 	media/webrtc/trunk/webrtc/system_wrappers/source/thread_posix.cc
Ø 15 	libsystem_pthread.dylib 	libsystem_pthread.dylib@0x3c12 	
Ø 16 	libsystem_pthread.dylib 	libsystem_pthread.dylib@0x3b8f 	
Ø 17 	libsystem_pthread.dylib 	libsystem_pthread.dylib@0x1374 	
18 	XUL 	XUL@0x27e0f0f

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

Is is possible something pulled the rug out from under the encoder and freed the source image while vp8 was encoding it?

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

Are all the crashes here from sharing?

Comment 6

[Maire Reavy [:mreavy]]

Hey Ralph -- Would you have time to look at this?  The VP8 code is blowing up , but it probably isn't a bug in upstream.  It's probably in the code that feeds the encoder.  Do you think you could help us narrow this down and at least eliminate the possibility of it being an upstream bug?  Thanks.

Comment 7

[Ian Bicking (:ianbicking)]

Yes, these are all from sharing.  They also all happened (including the crashes in Bug 1256711) when switching tabs in some fashion, which might support the theory in Comment 3

Comment 8

[Ian Bicking (:ianbicking)]

And another when switching tabs: https://crash-stats.mozilla.com/report/index/7f876fcf-4863-4000-821b-92b2e2160322

Comment 9

[Ralph Giles (:rillian)]

It's not obvious what else could be going on. In the MacOS X 10.11 _string.h:83 is a strcpy() implementation, which copy_and_extend_plane() doesn't call. It does call memcpy() and memset() though, so an invalid source or destination pointer are the obvious culprits.

Comment 10

[Randell Jesup [:jesup] (needinfo me)]

I'm still betting on someone freeing the source image.  What we really want here is an ASAN build to get a backtrace of who freed it.

I tried to repro on a mac with a local (non-ASAN) build, but I couldn't even get it to share the tab.  Once or twice I got either the tab to share or video, but usually the video was one-way.  Once I had two-way video, but no share.  Most times I got nothing at either end.  (4/1 Nightly and Aurora as link-clickers,fresh inbound build (debug) on mac as creator/sharer (of Google.com).

Ian: how to I repro this?  Is it broken currently?  I've done loop calls many times in my house before, though not usually with screensharing.  I have no trouble making talky.io/etc calls.  Note: the mac was probably running e10s - fresh profile on an inbound tree - does that work?

Comment 11

[Ian Bicking (:ianbicking)]

I've encountered it organically several separate times, but my attempts to reproduce it have not been successful.  When it has happened I have not been using e10s, and there are e10s issues that you might be encountering (though I'm not familiar with anything that would cause what you describe).

It occurs to me that there was a bug in Hello that could cause the tab sharing encoding to happen multiple times simultaneously, when a certain pattern of connection loss and reconnection happened (which typically doesn't happen when testing locally).  Mark: does that seem possible to you?  The most recent crash I had was https://crash-stats.mozilla.com/report/index/4b431f1e-57a7-4ece-820b-544f42160328 – which says I had v1.2.1 installed (though since it was built from source that doesn't say exactly what I was using), would that have had the state machine fix in it?

Comment 12

[Mark Banner (:standard8)]

1.2.1 included the fix (which was bug 1257009).

Comment 13

[Randell Jesup [:jesup] (needinfo me)]

Can't be 100% certain, but really appears to be a dup of bug 1263384.  Stack is identical.