[Tracking Requested - why for this release]: Nominating for tracking to keep on eye on this new signature. This bug was filed from the Socorro interface and is report bp-0ab3f74e-869e-492f-946d-af85f2161005. ============================================================= Seen while looking at crash-stats: http://bit.ly/2dSPwPG. New crash in beta - #14 top crash.

This looks like a media bug. Here's one crash which has some logcat output: https://crash-stats.mozilla.com/report/index/f2f708fc-492a-4a4c-9f1c-290ba2161001#tab-metadata The last few lines before crashing: 10-01 16:20:46.077 28927 31089 I OMXClient: Using client-side OMX mux. 10-01 16:20:46.077 28927 31089 I : new RKOMXPlugin 10-01 16:20:46.077 28927 31089 D ACodec : MEDIA_MIMETYPE_AUDIO_AAC sampleRate 22050 wifidisplay_flag 0 info 9530de78 10-01 16:20:46.077 28927 31089 E OMXNodeInstance: OMX_GetExtensionIndex failed 10-01 16:20:46.097 28927 31095 I OMXClient: Using client-side OMX mux. 10-01 16:20:46.097 28927 31095 E ACodec : Unable to instantiate a decoder for type 'video/avc'. 10-01 16:20:46.097 28927 31094 E MediaCodec: Codec reported an error. (omx error 0x80001003, internalError -2147483648) 10-01 16:20:46.147 28927 30984 W google-breakpad: ExceptionHandler::GenerateDump cloned child 10-01 16:20:46.147 28927 30984 W google-breakpad: 31097 10-01 16:20:46.147 28927 30984 W google-breakpad: 10-01 16:20:46.147 28927 30984 W google-breakpad: ExceptionHandler::SendContinueSignalToChild sent continue signal to child 10-01 16:20:46.147 31097 31097 W google-breakpad: ExceptionHandler::WaitForContinueSignal waiting for continue signal...

Hello Chris, Jean-Yves, this is a new crash in Fennec50. Could you please help find an owner? Thanks!

It's ranked #15 in Fennec 50 top crashers.

Blake is managing Android video playback. Passing ni? to him.

Chris, Thanks for letting me know. James, Please help this bug. Thanks!

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #1) > This looks like a media bug. Here's one crash which has some logcat output: > > https://crash-stats.mozilla.com/report/index/f2f708fc-492a-4a4c-9f1c- > 290ba2161001#tab-metadata > > The last few lines before crashing: > > 10-01 16:20:46.077 28927 31089 I OMXClient: Using client-side OMX mux. > 10-01 16:20:46.077 28927 31089 I : new RKOMXPlugin > 10-01 16:20:46.077 28927 31089 D ACodec : MEDIA_MIMETYPE_AUDIO_AAC > sampleRate 22050 wifidisplay_flag 0 info 9530de78 > 10-01 16:20:46.077 28927 31089 E OMXNodeInstance: OMX_GetExtensionIndex > failed > 10-01 16:20:46.097 28927 31095 I OMXClient: Using client-side OMX mux. > 10-01 16:20:46.097 28927 31095 E ACodec : Unable to instantiate a decoder > for type 'video/avc'. > 10-01 16:20:46.097 28927 31094 E MediaCodec: Codec reported an error. (omx > error 0x80001003, internalError -2147483648) > 10-01 16:20:46.147 28927 30984 W google-breakpad: > ExceptionHandler::GenerateDump cloned child > 10-01 16:20:46.147 28927 30984 W google-breakpad: 31097 > 10-01 16:20:46.147 28927 30984 W google-breakpad: > 10-01 16:20:46.147 28927 30984 W google-breakpad: > ExceptionHandler::SendContinueSignalToChild sent continue signal to child > 10-01 16:20:46.147 31097 31097 W google-breakpad: > ExceptionHandler::WaitForContinueSignal waiting for continue signal... Hi kats, I would like to know where did you get the logcat from those links. I cannot find out the logcat information... Thanks.

From the logcat snippet, I can see we cannot create the decoder for video/avc which is not a normal situation since H264 is very common. The error 0x80001003 means "No component with the specified name string was found" [1] But that error is not related to crash I think. From the call stack[2], it seems the "audio" decoder can be created but bump into crash when invoking DequeueOutputBuffer. This is where C++ wants to invoke JAVA code throgh JNI but I have no idea why ```__aeabi_fcmpgt``` got involved with the callstack and crash in libdvm.so. Hi Jim, Do you have any idea about this point(__aeabi_fcmpgt and JNI)? Thanks. [1] http://androidxref.com/6.0.1_r10/xref/frameworks/native/include/media/openmax/OMX_Core.h#157 [2] https://crash-stats.mozilla.com/report/index/f2f708fc-492a-4a4c-9f1c-290ba2161001#tab-details

The other things that I noticed is that we create 900+ decoder threads(which means 900+ decoder) in the same time. I don't know if this situation is caused by the fennec user with some abnormal manipulation or there are some bugs in gecko. I will try to dig out if there is any code defect that will repeatedly create decoder. BTW, since we introduce OOP decoding architecture in bug 1257777, the fennec will not crash logically... So maybe this is the alternative solution for this bug.

You need to request permission to view the hidden crash report fields if you don't have it already. The logcat is privacy sensitive just like URLs so you need special permission to access it. If you have permissions on your account, make sure you are logged in to socorro. I can also pull out the full logcat dump from that crashreport for you if you'd like. Note that not all the crashes will have logcat.

A lot of the logs indicate OOM, so maybe we're creating too many decoder threads or forgot to terminate them. Can we limit to one or a few decoder threads?

Hi kats, Referring to the permission, where can I apply for the special permission? Thanks.

(In reply to Jim Chen [:jchen] [:darchons] from comment #10) > A lot of the logs indicate OOM, so maybe we're creating too many decoder > threads or forgot to terminate them. Can we limit to one or a few decoder > threads? There's already a mechanism in place, introduced in bug 1214710. This is controlled by a pref media.decoder.limit But in any case, if the issue is with decoder not being freed, this is what needs to be fixed and not paper around the problem by simply limiting how many we create at once. OUt of Process decoding is currently set for Windows decoder..

(In reply to James Cheng[:JamesCheng] from comment #11) > Hi kats, > > Referring to the permission, where can I apply for the special permission? > > Thanks. I got it back in the day by filing a bug - see https://bugzilla.mozilla.org/show_bug.cgi?id=818898. I'm not sure how one goes about it today.

(In reply to Jean-Yves Avenard [:jya] from comment #12) > OUt of Process decoding is currently set for Windows decoder.. We are using this mechanism on Fennec as well. Bug 1257777 is about it.

Hi jya, I saw the comment 12 you indicated that we have some mechanism to restrict the number of decoder creation. For [1], does it means there are no decoder limit on all platform except Fennec which is under API Level 18? Because I can only found the decoder is created numerous by crash report. Should we need to file another bug to limit the number of decoder creation on Fennec even API Level is higher than 18? [1] http://searchfox.org/mozilla-central/rev/d96317a351af8aa78ab9847e7feed964bbaac7d7/dom/media/MediaPrefs.h#175

(In reply to James Cheng[:JamesCheng] from comment #15) > Hi jya, > > I saw the comment 12 you indicated that we have some mechanism to restrict > the number of decoder creation. > > For [1], does it means there are no decoder limit on all platform except > Fennec which is under API Level 18? the limit was set for < 18 because simply creating more than 2 MP3 decoders would cause a crash unrelated to OOM. However, if the issue is due to OOM and the non-handling of those, it seems to me that limiting the number of decoders open at any one time is just papering over the real problem. It's not a fix as such. Bug 1311872 would be a better work around than limiting the number of live decoders that is defined by platforms.

The symptom of this bug is that we create lots of decoder and crash with OOM. Since Bug 1311872 is landing, I think the OOM symptom will be eased.

[Tracking Requested - why for this release]: Too late to take a fix for this in 50. Nom'ing for tracking in 51.

Track 51- as there are no crashes in 51 for now.

Per comment 19.