Crash occurred in gmpopenh264 when running




5 years ago
4 years ago


(Reporter: frank.coco, Unassigned)


37 Branch
Windows 7
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




5 years ago
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 
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.

Comment 1

5 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.
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\ @ 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\ @ 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  

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.

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",

    // 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;
      case GMP_BufferLength8:
        size_bytes = 1;
      case GMP_BufferLength16:
        size_bytes = 2;
      case GMP_BufferLength24:
        size_bytes = 3;
      case GMP_BufferLength32:
        size_bytes = 4;
        // Really that it's not in the enum
            ("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

    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();
        case GMP_BufferLength8:
          size = *buffer++;
        case GMP_BufferLength16:
          // presumes we can do unaligned loads
          size = *(reinterpret_cast<uint16_t*>(buffer));
          buffer += 2;
        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;
        case GMP_BufferLength32:
          // presumes we can do unaligned loads
          size = *(reinterpret_cast<uint32_t*>(buffer));  <--- Line 479
          buffer += 4;
          break; // already handled above
      if (buffer+size > end) {
        // XXX see above - should we kill the plugin for returning extra bytes?  Probably
            ("GMP plugin returned badly formatted encoded data: end is %td bytes past buffer end",
             buffer+size - end));
      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):

And on a new, empty profile:
Flags: needinfo?(frank.coco)

Comment 3

5 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)
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\ 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

Comment 6

5 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 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.
Closed: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.