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)

37 Branch
x86_64
Windows 7
defect
Not set
normal

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.
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)); } } }
Component: General → WebRTC: Audio/Video
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)
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)
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.
Flags: needinfo?(frank.coco)
I'm guessing this could be solved by having a Win64 release of OpenH264 so making it dep on bug 1113777
Depends on: 1113777
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)
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.