Closed
Bug 1113806
Opened 10 years ago
Closed 10 years ago
Crash occurred in gmpopenh264 when running mozilla.github.io/webrtc-landing/pc_test.html
Categories
(Core :: WebRTC: Audio/Video, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: frank.coco, Unassigned)
References
Details
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36
Steps to reproduce:
1) I installed the 12/18/14 nightly firefox on Windows 7 Professional SP1 64 bit PC.
2) I loaded mozilla.github.io/webrtc-landing/pc_test.html.
3) I selected "Use Fake Audio/Video for one stream" and "Require H.264 video"
4) Hit Start
Actual results:
gmpopenh264 crashed
Expected results:
I should have seen 2-way video.
Reporter | ||
Comment 1•10 years ago
|
||
Below is some potentially useful data while trying to debug the crash.
(960.e7c): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
xul!mozilla::WebrtcGmpVideoEncoder::Encoded+0xde:
6c673840 8b1f mov ebx,dword ptr [edi] ds:002b:00000000=????????
# 29 Id: 960.e7c Suspend: 1 Teb: fff5f000 Unfrozen "GMPEncoded"
ChildEBP RetAddr
1a7ffb44 6c797f31 xul!mozilla::WebrtcGmpVideoEncoder::Encoded(class GMPVideoEncodedFrame * aEncodedFrame = 0x00000004, class nsTArray<unsigned char> * aCodecSpecificInfo = 0x0e6fc890)+0xde [c:\builds\moz2_slave\rel-m-rel-34.1-w32_bld-0000000\build\media\webrtc\signaling\src\media-conduit\webrtcgmpvideocodec.cpp @ 479]
1a7ffb5c 6c797b71 xul!mozilla::gmp::EncodedCallback(class GMPVideoEncoderCallbackProxy * aCallback = 0x1113fb08, class GMPVideoEncodedFrame * aEncodedFrame = 0x0d35aec0, class nsTArray<unsigned char> * aCodecSpecificInfo = 0x0e6fc890, class nsCOMPtr<nsIThread> aThread = class nsCOMPtr<nsIThread>)+0x14 [c:\builds\moz2_slave\rel-m-rel-34.1-w32_bld-0000000\build\content\media\gmp\gmpvideoencoderparent.cpp @ 277]
1a7ffb74 6c31f418 xul!mozilla::runnable_args_nm_4<void (void)+0x23 [c:\builds\moz2_slave\rel-m-rel-34.1-w32_bld-0000000\build\media\mtransport\runnable_utils_generated.h @ 325]
1a7ffcec 6c344c6d xul!nsThread::ProcessNextEvent(bool aMayWait = true, bool * aResult = 0x1a7ffd04)+0x5e8 [c:\builds\moz2_slave\rel-m-rel-34.1-w32_bld-0000000\build\xpcom\threads\nsthread.cpp @ 824]
1a7ffcfc 6c4e672b xul!NS_ProcessNextEvent(class nsIThread * aThread = 0x079c1001, bool aMayWait = true)+0x2d [c:\builds\moz2_slave\rel-m-rel-34.1-w32_bld-0000000\build\xpcom\glue\nsthreadutils.cpp @ 265]
1a7ffd2c 6c4d927f xul!mozilla::ipc::MessagePumpForNonMainThreads::Run(class base::MessagePump::Delegate * aDelegate = 0x01e29980)+0xbb [c:\builds\moz2_slave\rel-m-rel-34.1-w32_bld-0000000\build\ipc\glue\messagepump.cpp @ 368]
1a7ffd64 6c4d9333 xul!MessageLoop::RunHandler(void)+0x51 [c:\builds\moz2_slave\rel-m-rel-34.1-w32_bld-0000000\build\ipc\chromium\src\base\message_loop.cc @ 228]
1a7ffd84 6c42e364 xul!MessageLoop::Run(void)+0x19 [c:\builds\moz2_slave\rel-m-rel-34.1-w32_bld-0000000\build\ipc\chromium\src\base\message_loop.cc @ 202]
1a7ffd9c 747c24d7 xul!nsThread::ThreadFunc(void * aArg = 0x01e29980)+0x87 [c:\builds\moz2_slave\rel-m-rel-34.1-w32_bld-0000000\build\xpcom\threads\nsthread.cpp @ 359]
1a7ffdbc 747b233d nss3!_PR_NativeRunThread(void * arg = 0x0fd1d290)+0x167 [c:\builds\moz2_slave\rel-m-rel-34.1-w32_bld-0000000\build\nsprpub\pr\src\threads\combined\pruthr.c @ 419]
1a7ffdc4 7498c6de nss3!pr_root(void * arg = 0x0fd1d290)+0xd [c:\builds\moz2_slave\rel-m-rel-34.1-w32_bld-0000000\build\nsprpub\pr\src\md\windows\w95thred.c @ 90]
1a7ffdfc 7498c788 MSVCR100!_callthreadstartex(void)+0x1b [f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c @ 314]
1a7ffe08 7587338a MSVCR100!_threadstartex(void * ptd = 0x0061cb18)+0x64 [f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c @ 292]
1a7ffe14 77b89f72 kernel32!BaseThreadInitThunk+0xe
1a7ffe54 77b89f45 ntdll32!__RtlUserThreadStart+0x70
1a7ffe6c 00000000 ntdll32!_RtlUserThreadStart+0x1b
I downloaded the source for v34.0.5 from ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/34.0.5/source/.
The relevant function is below, crashing line is highlighted.
It looks like this callback function is getting a NULL buffer to work with. Seems at a minimum this function should check what aEncodedFrame->Buffer() returns.
void
WebrtcGmpVideoEncoder::Encoded(GMPVideoEncodedFrame* aEncodedFrame,
const nsTArray<uint8_t>& aCodecSpecificInfo)
{
if (mCallback) { // paranoia
webrtc::VideoFrameType ft;
GmpFrameTypeToWebrtcFrameType(aEncodedFrame->FrameType(), &ft);
uint32_t timestamp = (aEncodedFrame->TimeStamp() * 90ll + 999)/1000;
LOGD(("GMP Encoded: %llu, type %d, len %d",
aEncodedFrame->TimeStamp(),
aEncodedFrame->BufferType(),
aEncodedFrame->Size()));
// Right now makes one Encoded() callback per unit
// XXX convert to FragmentationHeader format (array of offsets and sizes plus a buffer) in
// combination with H264 packetization changes in webrtc/trunk code
uint8_t *buffer = aEncodedFrame->Buffer();
uint8_t *end = aEncodedFrame->Buffer() + aEncodedFrame->Size();
size_t size_bytes;
switch (aEncodedFrame->BufferType()) {
case GMP_BufferSingle:
size_bytes = 0;
break;
case GMP_BufferLength8:
size_bytes = 1;
break;
case GMP_BufferLength16:
size_bytes = 2;
break;
case GMP_BufferLength24:
size_bytes = 3;
break;
case GMP_BufferLength32:
size_bytes = 4;
break;
default:
// Really that it's not in the enum
LOG(PR_LOG_ERROR,
("GMP plugin returned incorrect type (%d)", aEncodedFrame->BufferType()));
// XXX Bug 1041232 - need a better API for interfacing to the
// plugin so we can kill it here
return;
}
uint32_t size;
// make sure we don't read past the end of the buffer getting the size
while (buffer+size_bytes < end) {
switch (aEncodedFrame->BufferType()) {
case GMP_BufferSingle:
size = aEncodedFrame->Size();
break;
case GMP_BufferLength8:
size = *buffer++;
break;
case GMP_BufferLength16:
// presumes we can do unaligned loads
size = *(reinterpret_cast<uint16_t*>(buffer));
buffer += 2;
break;
case GMP_BufferLength24:
// 24-bits is a pain, since byte-order issues make things painful
// I'm going to define 24-bit as little-endian always; big-endian must convert
size = ((uint32_t) *buffer) |
(((uint32_t) *(buffer+1)) << 8) |
(((uint32_t) *(buffer+2)) << 16);
buffer += 3;
break;
case GMP_BufferLength32:
// presumes we can do unaligned loads
size = *(reinterpret_cast<uint32_t*>(buffer)); <--- Line 479
buffer += 4;
break;
default:
break; // already handled above
}
if (buffer+size > end) {
// XXX see above - should we kill the plugin for returning extra bytes? Probably
LOG(PR_LOG_ERROR,
("GMP plugin returned badly formatted encoded data: end is %td bytes past buffer end",
buffer+size - end));
return;
}
webrtc::EncodedImage unit(buffer, size, size);
unit._frameType = ft;
unit._timeStamp = timestamp;
unit._completeFrame = true;
mCallback->Encoded(unit, nullptr, nullptr);
buffer += size;
// on last one, buffer == end normally
}
if (buffer != end) {
// At most 3 bytes can be left over, depending on buffertype
LOGD(("GMP plugin returned %td extra bytes", end - buffer));
}
}
}
Updated•10 years ago
|
Component: General → WebRTC: Audio/Video
Comment 2•10 years ago
|
||
Works for me on 37.0a1 (2015-01-12) Win 7.
Please check if the issue occurs using Firefox in safe mode (with your addons disabled):
http://support.mozilla.com/kb/Safe+Mode
And on a new, empty profile:
http://support.mozilla.org/en-US/kb/Managing-profiles#w_starting-the-profile-manager
Flags: needinfo?(frank.coco)
Reporter | ||
Comment 3•10 years ago
|
||
I updated my firefox to 37.0a1 (2015-01-12 Win 7 SP1 64-bit.
If I run in safe mode I still get the crash, e.g. "The gmpopenh264 has crashed".
If I start the profile manager an use my "default" profile, it still crashes.
If I start the profile manager and create a new profile called "empty", it no longer crashes. However I don't have 2-way video, I can only see the local camera.
Hope that helps.
Flags: needinfo?(frank.coco)
Comment 4•10 years ago
|
||
There is no 64-bit version of the plugin; if you're using a 64-bit Firefox - which you appear to be) then the 32-bit plugin will not work (it's a bug that it crashes; it shouldn't load at all). The next version of the plugin will likely have a 64-bit version. We're not shipping win64 builds in release yet so far as I know.
If you are using win32 builds:
Please wait at least 1-2 minutes after creating the new profile and starting the browser (you can watch the AddOns page for Plugins to see when OpenH264 has been downloaded. Then try again.
Also, please check what's in your profile (you can easily get to it from Help->Troubleshooting) for gmp-gmpopenh264\1.1\gmpopenh264.info and the size of the dll in that directory (I have 560640). If you have a new win64 profile, it will fail to find a plugin to download.
Updated•10 years ago
|
Flags: needinfo?(frank.coco)
Comment 5•10 years ago
|
||
I'm guessing this could be solved by having a Win64 release of OpenH264 so making it dep on bug 1113777
Depends on: 1113777
Reporter | ||
Comment 6•10 years ago
|
||
I did load the 64-bit Nightly Firefox so I guess I'm out luck. I'll wait for the 64 bit version of the plugin.
As far as my profile, the size of my dll is also 560640. The contents of gmpopenh264.info is the following:
Name: gmpopenh264
Description: GMP Plugin for OpenH264
Version: 1.0
APIs: encode-video[h264], decode-video[h264]
Thanks for the help!
Flags: needinfo?(frank.coco)
Comment 7•10 years ago
|
||
OpenH264 1.3 includes a Win64 build and is now downloaded for Firefox 34+ so marking this as fixed.
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•