Updating that the problem still exists in chromium-55.0.2883.44.
Stack trace:

Received signal 11 SEGV_MAPERR fffffffd4f6f79cc
#0 0x56121242fc6e <unknown>
#1 0x56121243002b <unknown>
#2 0x7f66f9d56e20 <unknown>
#3 0x7f66f2711f12 vpx_codec_destroy
#4 0x561216547122 <unknown>
#5 0x561216531a51 <unknown>
#6 0x56121653238b <unknown>
#7 0x561216532460 <unknown>
#8 0x561216536414 <unknown>
#9 0x561216536826 <unknown>
#10 0x561216518405 <unknown>
#11 0x561215c8cba5 <unknown>
#12 0x561215c8cbc9 <unknown>
#13 0x7f66f9d4d494 start_thread
#14 0x7f66efeeb5dd clone
  r8: 0000000000000009  r9: 00007f66f2a74ac0 r10: 00002483bfdbf160 r11: fffffffd4f6f79ac
 r12: 00002483bfbdf560 r13: 00002483bfd34008 r14: 00002483bfbdf480 r15: 0000000000000064
  di: 0000000000000079  si: 00002483bfdbfdc0  bp: 00002483bfd2ee98  bx: 00002483c0042500
  dx: fffffffd4f6f79ac  ax: 0000000000000001  cx: 0000000000010000  sp: 00007f66d2601860
  ip: 00007f66f2711f12 efl: 0000000000010202 cgf: 002b000000000033 erf: 0000000000000005
 trp: 000000000000000e msk: 0000000000000000 cr2: fffffffd4f6f79cc
[end of stack trace]

Unable to reproduce this issue on Ubuntu 14.04 with chrome beta 55.0.2883.28.
These are the steps i have followed 
1. Opened the google chrome
2. Opened the url "https://test.webrtc.org/"
3. Clicked on the start button

No Crash is observed. please look into the attached screencast and let us know your observations.

Thank you...

Deleted: Issue 663293.webm 5.4 MB

	Issue 663293.webm 5.4 MB View Download

Hi,
thanks for taking the time. Attaching my screen shot.
The main difference I notice is that I'm not using Flash (I'm avoising close source binaries). Could this be a reason?

Deleted: chromium.webm 1.5 MB

	chromium.webm 1.5 MB View Download

Unable to reproduce the issue, even with flash disabled.

Please look into the attached screen-cast and let us know your observations.

Deleted: Issue 663293 (2).webm 5.7 MB

	Issue 663293 (2).webm 5.7 MB View Download

Missed the below details in the above comment:

Issue was rechecked on updated version of Chrome beta 55.0.2883.52 on Ubuntu 14.04

doronf.public@ Could you please update your chrome to latest beta version and let us know if the issue still exists. Also can you please help us with a crash ID generated from chrome://crashes. This will help us to triage the issue better.

Thanks.!

Hey,
sorry for the delay (it takes me ~4 hours to compile each version).
Attaching a screenshot of the same crash on Chrome beta 55.0.2883.52 on Gentoo (Portage 2.3.0 (python 3.4.3-final-0, default/linux/amd64/13.0/no-multilib, gcc-4.9.3, glibc-2.22-r4, 4.8.6-gentoo x86_64)).

Unfortunately I'm missing the option to generate crash reports as you can see in the attached png file. Let me know how to enable it.

In the meantime, here's the generated stack trace:
Received signal 11 SEGV_MAPERR fffffffd5357b838
#0 0x55950a758f5e <unknown>
#1 0x55950a75931b <unknown>
#2 0x7f9bec4e1e20 <unknown>
#3 0x7f9be4e9cf12 vpx_codec_destroy
#4 0x55950e871a02 <unknown>
#5 0x55950e85c331 <unknown>
#6 0x55950e85cc6b <unknown>
#7 0x55950e85cd40 <unknown>
#8 0x55950e860cf4 <unknown>
#9 0x55950e861106 <unknown>
#10 0x55950e842ce5 <unknown>
#11 0x55950dfb7455 <unknown>
#12 0x55950dfb7479 <unknown>
#13 0x7f9bec4d8494 start_thread
#14 0x7f9be26765dd clone
  r8: 0000000000000009  r9: 00007f9be51ffac0 r10: 00007f9bc3d9a740 r11: fffffffd5357b818
 r12: 00003897892b5300 r13: 0000389789525008 r14: 00003897892b5130 r15: 0000000000000064
  di: 0000000000000079  si: 000038978933e6e0  bp: 000038978951be98  bx: 00003897897dc940
  dx: fffffffd5357b818  ax: 0000000000000001  cx: 0000000000010000  sp: 00007f9bc3d9a860
  ip: 00007f9be4e9cf12 efl: 0000000000010202 cgf: 002b000000000033 erf: 0000000000000005
 trp: 000000000000000e msk: 0000000000000000 cr2: fffffffd5357b838
[end of stack trace]
 

Deleted: 55.0.2883.52.webm 1.9 MB

	55.0.2883.52.webm 1.9 MB View Download

Deleted: Screenshot_20161120_131001.png 67.7 KB

	Screenshot_20161120_131001.png 67.7 KB View Download

reaching out to  tommi@ and magjed@ from Webrtc to check if they can help us get this issue checked.

Updating on something I tired; 
In Gentoo the default is to use system-ffmpeg.
I changed it to use the bundled ffmpeg, to see if this helps.
Sadly this is not helping and I got the same results. This means that the
media codecs are not the issue.

I don't think this is a webcam issue since vpx_codec_destroy is part of the stack trace.

doronf.public@ - Can you confirm this by only trying the webcam with e.g. https://webrtc.github.io/samples/src/content/getusermedia/gum/?

You should probably add someone that works with video codecs here. If someone can reproduce, we should be able to bisect this.

cc'ing dalecurtis@ and 	hubbe@ to get more insights on Video codecs.

+vpx folk

Confirming magjed's claim using-
https://webrtc.github.io/samples/src/content/getusermedia/gum/?

(Attached screenshot).

Deleted: webrtc_20161123_100019.png 586 KB

	webrtc_20161123_100019.png 586 KB View Download

It's hard to say whether this is a vpx issue, a webrtc one or something else without a more complete stacktrace. The destroy call will crash if an uninitialized (non-zeroed) codec context is passed to it for instance.

There should be an option named "Automatically send usage statistics and crash reports to Google" that you'd need to enable for crash dumps to work.  However, could it be that you're not actually using Google Chrome, but rather Chromium?

@tommi I added a screenshot (PNG) to show I do not have the option.
And yes I am using Chromium which worked well until (including) chromium-53.0.2785.143. Starting chromium-54.0.2840.59 this issue showed up.

Since we don't have symbols or even an offset from vpx_codec_destroy, we don't know much about the crash. vpx_codec_destroy might not be on the stack at all but shows up there due to being the closest public export (I'm theorizing). We don't distribute or support chromium builds so I don't suppose you could try the same using chrome? 

If you can tell me how to add symbols, I'll recompile chromium and give you the information.

As for Chrome, I was able to install  www-client/google-chrome version 54.0.2840.100 (64-bit) . This is the binary distribution which comes with Flash and everything else bundled. I can confirm that the issue did NOT reproduce on Chrome.

However I'd still like to find the problem in Chromium. What would be the next step?

Interesting.  Well, I guess attaching a debugger would be the next step.  Also make sure you run Chromium from the command line in case you can get some log entries that can help.

doronf.public@ Is there any latest update available on this issue? Could you please respond for the comment #20 .

Thanks!

Hi,
I attached gdb and attached is the output I got.
The main thing I noticed is:
0x00007fbd9cf91f12 in vpx_codec_destroy () from /usr/lib64/libvpx.so.3

I'm now recompiling chromium with a newer version of libvpx (media-libs/libvpx-1.6.0-r1:0/4::gentoo) and if an API changed it may resolve the issue. I'll check and let you know.

In the meantime if you have any other idea, let me know.

Deleted: chromium-gdb.log 17.9 KB

chromium-gdb.log 17.9 KB View Download

What version is your system libvpx? There have been fixes around shutdown when dealing with threading, most that come to mind are in the decoder when dealing with corrupted data, though.
If you can install the debug symbols for your system lib you should be able to get a better backtrace.

@jzern I was using libvpx-1.5.0 and moved to libvpx-1.6.0-r1 with the hope
it'll resolve the issue, but sadly it did not.

I'll look into adding debug symbols for a better trace and update.

Hi,
It took me a while to recompile Chromium with the symbols.

I'm now running it with:
chromium --disable-extensions --disable-plugins --no-sandbox --renderer-cmd-prefix="xterm -e gdb -ex run --args"

and I can see the symbols are being used:
Reading symbols from /usr/lib64/chromium-browser/chrome...Reading symbols from /usr/lib64/debug//usr/lib64/chromium-browser/chrome.debug...done.
done.

Now the backtrace produces this:
(gdb) backtrace
#0  vpx_codec_destroy (ctx=0x333501307680) at /usr/src/debug/media-libs/libvpx-1.6.0-r1/libvpx-1.6.0/vpx/src/vpx_codec.c:91
#1  0x000055555b8edea2 in webrtc::VP8DecoderImpl::Release() ()
#2  0x000055555b8d87d1 in webrtc::VCMCodecDataBase::ReleaseDecoder(webrtc::VCMGenericDecoder*) const ()
#3  0x000055555b8d910b in webrtc::VCMCodecDataBase::CreateAndInitDecoder(webrtc::VCMEncodedFrame const&, webrtc::VideoCodec*) const ()
#4  0x000055555b8d91e0 in webrtc::VCMCodecDataBase::GetDecoder(webrtc::VCMEncodedFrame const&, webrtc::VCMDecodedFrameCallback*) ()
#5  0x000055555b8dd194 in webrtc::vcm::VideoReceiver::Decode(webrtc::VCMEncodedFrame const&) ()
#6  0x000055555b8dd5a6 in webrtc::vcm::VideoReceiver::Decode(unsigned short) ()
#7  0x000055555b8bf185 in webrtc::internal::VideoReceiveStream::DecodeThreadFunction(void*) ()
#8  0x000055555b0360b5 in rtc::PlatformThread::Run() ()
#9  0x000055555b0360d9 in rtc::PlatformThread::StartThread(void*) ()
#10 0x00007ffff7bc6494 in start_thread () from /lib64/libpthread.so.0
#11 0x00007fffedcd25dd in clone () from /lib64/libc.so.6

I'm attaching the full log of the gdb session. Please take a look and let me know if something else is needed.

Deleted: chromium-gdb2.log 5.1 KB

chromium-gdb2.log 5.1 KB View Download

Magnus can you take a look at this?

From what it looks like, here's what's happening.

1. We're inside VCMCodecDataBase::CreateAndInitDecoder.
2. The call to VP8DecoderImpl::InitDecode fails.
  - Here, I'm wondering if this part is buggy.  (really hope this isn't supposed to be reference counting!)

int VP8DecoderImpl::InitDecode(const VideoCodec* inst, int number_of_cores) {
  int ret_val = Release();  <--- ???
  if (ret_val < 0) {
    return ret_val;
  }
  ...

3. Release() gets called again when InitDecode fails and that's where we crash.


vpx_codec_destroy could be hitting this case:

  if (!ctx)
    res = VPX_CODEC_INVALID_PARAM;
  else if (!ctx->iface || !ctx->priv)
    res = VPX_CODEC_ERROR;  <---  Here.
  ...


Another thing, and perhaps more likely, is that vpx_codec_dec_init is failing inside InitDecode.  In that case, we've allocated a |decoder_| instance, failed to initialize it but don't free the |decoder_|.  VP8DecoderImpl::Release() will try to use that object, but it's not in a known, reliable state.

Yes, the second case you describe seems to be the issue. From looking at the code, it's not safe to call vpx_codec_destroy if vpx_codec_dec_init failed, because the |decoder_| memory will be uninitialized.

I think we should do this change:
   if (vpx_codec_dec_init(decoder_, vpx_codec_vp8_dx(), &cfg, flags)) {
+    delete decoder_;
+    decoder_ = nullptr;
     return WEBRTC_VIDEO_CODEC_MEMORY;
   }

We should probably also do this, just in case:
   if (decoder_ == NULL) {
     decoder_ = new vpx_codec_ctx_t;
+    memset(decoder_, 0, sizeof(*decoder_));
   }

Thanks for fixing this so quickly magjed!

The following revision refers to this bug:
  https://chromium.googlesource.com/external/webrtc.git/+/5c71166dffb49510092bf87f271b6ea590acd1f1

commit 5c71166dffb49510092bf87f271b6ea590acd1f1
Author: magjed <magjed@webrtc.org>
Date: Fri Dec 02 10:46:18 2016

VP8DecoderImpl: Fix uninitialized memory crash

It is not safe to call vpx_codec_destroy if vpx_codec_dec_init failed,
because the |decoder_| memory will be uninitialized. See the bug for
more info.

BUG= chromium:663293 

Review-Url: https://codereview.webrtc.org/2541163007
Cr-Commit-Position: refs/heads/master@{#15381}

[modify] https://crrev.com/5c71166dffb49510092bf87f271b6ea590acd1f1/webrtc/modules/video_coding/codecs/vp8/vp8_impl.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/external/webrtc.git/+/5c71166dffb49510092bf87f271b6ea590acd1f1

commit 5c71166dffb49510092bf87f271b6ea590acd1f1
Author: magjed <magjed@webrtc.org>
Date: Fri Dec 02 10:46:18 2016

VP8DecoderImpl: Fix uninitialized memory crash

It is not safe to call vpx_codec_destroy if vpx_codec_dec_init failed,
because the |decoder_| memory will be uninitialized. See the bug for
more info.

BUG= chromium:663293 

Review-Url: https://codereview.webrtc.org/2541163007
Cr-Commit-Position: refs/heads/master@{#15381}

[modify] https://crrev.com/5c71166dffb49510092bf87f271b6ea590acd1f1/webrtc/modules/video_coding/codecs/vp8/vp8_impl.cc

Hi guys,
just wanted to let you know I manually applied the patch on 55.0.2883.75 (the code is not the same), and the fix works.

How can I know which release will include this fix?

Thanks for verifying the fix. It will be included in M57 by default. The fix is simple and safe, so I think we should merge it to M56 if this is an important issue.

Your change meets the bar and is auto-approved for M56 (branch: 2924)

The following revision refers to this bug:
  https://chromium.googlesource.com/external/webrtc.git/+/ac061a9ab6ca6690acb6284c1ee34860927acfd7

commit ac061a9ab6ca6690acb6284c1ee34860927acfd7
Author: Magnus Jedvert <magjed@webrtc.org>
Date: Tue Dec 13 10:53:26 2016

VP8DecoderImpl: Fix uninitialized memory crash

It is not safe to call vpx_codec_destroy if vpx_codec_dec_init failed,
because the |decoder_| memory will be uninitialized. See the bug for
more info.

BUG= chromium:663293 
TBR=mflodman,tommi

Review-Url: https://codereview.webrtc.org/2566383003 .
Cr-Commit-Position: refs/branch-heads/56@{#7}
Cr-Branched-From: 613152af11d6e9a4d046af3c48a7be7642dfcc68-refs/heads/master@{#15101}

[modify] https://crrev.com/ac061a9ab6ca6690acb6284c1ee34860927acfd7/webrtc/modules/video_coding/codecs/vp8/vp8_impl.cc