962915 - VP8 Encoder initialization crash

Status: RESOLVED INCOMPLETE

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

Description

[Dan Mosedale (:dmosedale, :dmose)]

Attachment: crash-report.rtf

After checking in some code to Talkilla, our integration tests started failing intermittently.  I caught one of the failures in the act, and it turned out that one of the browsers (today's Nightly 2014-01-22) had crashed.


http://hg.mozilla.org/mozilla-central/rev/8f4ecbf938cd is the build id.

Excitingly, Breakpad didn't catch the crash, Apple's error reporter did.  Not so surprisingly, and presumably as a result, crash-stats.mozilla.org shows no instances of this crash.

It's hard to guess when the crash was introduced; it's possible it was a while ago, and we're just now triggering it for whatever reason.

The top of the stack looks like this, and I'll put the entire output from Apple's crash report:

0   libsystem_c.dylib             	0x00007fff8ddd0d7b bzero$VARIANT$sse42 + 155
1   XUL                           	0x000000010315b904 vp8_denoiser_allocate + 148
2   XUL                           	0x000000010318509b set_param + 955
3   XUL                           	0x00000001031fb4b3 vpx_codec_control_ + 227
4   XUL                           	0x0000000102cef8ba webrtc::VP8EncoderImpl::InitAndSetControlSettings(webrtc::VideoCodec const*) + 170
5   XUL                           	0x0000000102cef77a webrtc::VP8EncoderImpl::InitEncode(webrtc::VideoCodec const*, int, unsigned int) + 1306
6   XUL                           	0x0000000102cab7a7 webrtc::VCMCodecDataBase::SetSendCodec(webrtc::VideoCodec const*, int, int, webrtc::VCMEncodedFrameCallback*) + 711
7   XUL                           	0x0000000102cc418d webrtc::vcm::VideoSender::RegisterSendCodec(webrtc::VideoCodec const*, unsigned int, unsigned int) + 93
8   XUL                           	0x0000000102c50457 webrtc::ViEEncoder::UpdateProtectionMethod(bool) + 503
9   XUL                           	0x0000000102c61ee6 webrtc::ViERTP_RTCPImpl::SetNACKStatus(int, bool) + 214
10  XUL                           	0x0000000101915e5e mozilla::WebrtcVideoConduit::ConfigureRecvMediaCodecs(std::vector<mozilla::VideoCodecConfig*, std::allocator<mozilla::VideoCodecConfig*> > const&) + 1630
11  XUL                           	0x000000010191adc7 vcmRxStartICE_m(unsigned short, unsigned short, unsigned short, int, int, int, unsigned int, char const*, int, vcm_payload_info_t const*, sdp_setup_type_e, char const*, char const*, vcm_attrs_t_*) + 1399

Comment 1

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

Odd.  vpx_memalign()/VPX_MALLOC_ appears fallible, but it checks the result in  vp8_yv12_realloc_frame_buffer(), and the callers in vp8_denoiser_allocate() check the result.

Can we run this under ASAN with these tests?  Can this be run by hand?  does it fail a lot, always?  Which integration tests?  How do you run them?  Is it still failing?

Comment 2

[Dan Mosedale (:dmosedale, :dmose)]

(In reply to Randell Jesup [:jesup] from comment #1)
> Odd.  vpx_memalign()/VPX_MALLOC_ appears fallible, but it checks the result
> in  vp8_yv12_realloc_frame_buffer(), and the callers in
> vp8_denoiser_allocate() check the result.
> 
> Can we run this under ASAN with these tests?  

I don't know; I've never tried ASAN.  These are Talkilla functional tests, that use hacked up version of WebDriver to start Firefox for us.  It's hard to imagine that's not somehow doable.

> Does it fail a lot, always? Is it still failing?

Unclear.  It's been a while since I filed, and we haven't been touching Talkilla for some weeks now.

FWIW, I'm happy to close this bug as INCOMPLETE.

>  Which integration tests?  How do you run them?  

Talkilla functional tests.  Sometimes run under the control of travis-ci, other times by hand.  This particular crash was one that I caught by hand.  It's run by cloning the Talkilla github repo at https://github.com/mozilla/talkilla/ , setting up by doing the stuff described in the README, and then running "make selenium" from the top-level directory.

Comment 3

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

Derf: would you like to decide whether to keep this open or close as incomplete?

Comment 4

[Timothy B. Terriberry (:derf)]

(In reply to Randell Jesup [:jesup] from comment #1)
> Odd.  vpx_memalign()/VPX_MALLOC_ appears fallible, but it checks the result
> in  vp8_yv12_realloc_frame_buffer(), and the callers in
> vp8_denoiser_allocate() check the result.

Well, in a system with overcommit, it can return a non-NULL pointer and then segfault when it goes to actually map the pages. If that's what's going on, though, there isn't much we can do except crash.

Let's close as INCOMPLETE for now, though. Dan, if you ever run things in ASAN and find out more, feel free to reopen.