Crashing the plugin-container for GMP running H.264 brings down the whole browser.

RESOLVED DUPLICATE of bug 1163456

Status

()

RESOLVED DUPLICATE of bug 1163456
4 years ago
3 years ago

People

(Reporter: mconley, Unassigned)

Tracking

Trunk
Unspecified
Mac OS X
Points:
---

Firefox Tracking Flags

(firefox40 affected)

Details

(Reporter)

Description

4 years ago
STR:

1) Make sure e10s is _disabled_, and ensuring you're using a device with a camera.
2) Visit https://mozilla.github.io/webrtc-landing/pc_test.html
3) Click on the "Require H.264 video" checkbox, and then click "Start!"
4) Approve the usage of your camera for the test
5) You should see two images of your camera feed on the page, where the left one is going through the H.264 encoder.
6) Open the Activity Monitor, and find the plugin-container - this is where the GMP is running. Make note of the process ID.
7) In a Terminal, type in:

kill -SIGABRT [process ID]

(With no square brackets around the process ID).

ER:

The GMP should crash and we should see the plugin crash UI, which is a yellow bar at the top of the browser with the option for reloading the page or submitting a crash report.

AR:

Whole browser crashes.


Here's a backtrace from the crash:

#0  mozilla::WebrtcGmpVideoEncoder::Encode_g (this=0x1611f0a40, aInputImage=0x164cf4a90, aCodecSpecificInfo=0x0, aFrameTypes=0x164400668) at WebrtcGmpVideoCodec.cpp:326
#1  0x0000000102886e1e in mozilla::runnable_args_m_3_ret<mozilla::WebrtcGmpVideoEncoder*, int (mozilla::WebrtcGmpVideoEncoder::*)(webrtc::I420VideoFrame const*, webrtc::CodecSpecificInfo const*, std::vector<webrtc::VideoFrameType, std::allocator<webrtc::VideoFrameType> > const*), webrtc::I420VideoFrame const*, webrtc::CodecSpecificInfo const*, std::vector<webrtc::VideoFrameType, std::allocator<webrtc::VideoFrameType> > const*, int>::Run (this=0x128dc6a10) at runnable_utils_generated.h:303
#2  0x00000001016defb6 in mozilla::SyncRunnable::Run (this=0x11bc2d510) at SyncRunnable.h:75
#3  0x0000000101724d66 in nsThread::ProcessNextEvent (this=0x11bffa010, aMayWait=false, aResult=0x11cb80c6e) at nsThread.cpp:868
#4  0x000000010177ff98 in NS_ProcessNextEvent (aThread=0x11bffa010, aMayWait=false) at nsThreadUtils.cpp:265
#5  0x0000000101dc1569 in mozilla::ipc::MessagePumpForNonMainThreads::Run (this=0x11bfb4e00, aDelegate=0x11c5c2ad0) at MessagePump.cpp:326
#6  0x0000000101d33df5 in MessageLoop::RunInternal (this=0x11c5c2ad0) at message_loop.cc:233
#7  0x0000000101d33d05 in MessageLoop::RunHandler (this=0x11c5c2ad0) at message_loop.cc:226
#8  0x0000000101d33cad in MessageLoop::Run (this=0x11c5c2ad0) at message_loop.cc:200
#9  0x0000000101723206 in nsThread::ThreadFunc (aArg=0x11bffa010) at nsThread.cpp:364
#10 0x0000000101379e2f in _pt_root (arg=0x11be33d80) at /Users/mikeconley/Projects/mozilla-central/nsprpub/pr/src/pthreads/ptthread.c:212
#11 0x00007fff8c2a9772 in _pthread_start ()
#12 0x00007fff8c2961a1 in thread_start ()
Have you been able to reproduce (or try) something similar on Windows or Linux?

Do you have a regression range?
(Reporter)

Updated

4 years ago
Keywords: regressionwindow-wanted
Bug 1163456 is a dupe of this bug. However before I mark it as such: There's a proposed patch there, but I'm not sure if it's appropriate, could you please have a look?
Flags: needinfo?(mconley)
(Reporter)

Comment 3

4 years ago
I'm afraid I'm not qualified to answer that - the GMP backend is mostly a black box to me. cpearce or rjesup would probably be better advisers there.
Flags: needinfo?(mconley)
Depends on: 1163456
Should we go ahead and dupe this over?
Flags: needinfo?(rjesup)
Keywords: regressionwindow-wanted
Flags: needinfo?(rjesup) → needinfo?(mreavy)
Dup of now-fixed bug
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Flags: needinfo?(mreavy)
Resolution: --- → DUPLICATE
Duplicate of bug: 1163456
You need to log in before you can comment on or make changes to this bug.