Created attachment 8364102 [details] 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
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?
(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.
Derf: would you like to decide whether to keep this open or close as incomplete?
(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.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.