898767 - crash in mozilla::DecoderTraits::CanHandleMediaType

Status: RESOLVED WONTFIX

(Core :: Audio/Video: Playback, defect, P2)

Description

[Scoobidiver (away)]

It started spiking in 25.0a1/20130714 but is discontinuous across builds.

Signature 	mozilla::DecoderTraits::CanHandleMediaType(char const*, bool, nsAString_internal const&) More Reports Search
UUID 	96f2c74e-8ec6-4f98-9738-743fc2130727
Date Processed	2013-07-27 07:48:10.071754
Uptime	17
Last Crash	290341 seconds before submission
Install Age 	25513 since version was first installed.
Install Time 	2013-07-27 00:42:50
Product 	FennecAndroid
Version 	25.0a1
Build ID 	20130726030203
Release Channel 	nightly
OS 	Android
OS Version 	0.0.0 Linux 3.0.31-1098177 #1 SMP PREEMPT Fri Mar 29 10:58:51 KST 2013 armv7l Verizon/t0ltevzw/t0lte
Build Architecture 	arm
Build Architecture Info 	ARMv0 | 4
Crash Reason 	SIGSEGV
Crash Address 	0x76
App Notes 	
AdapterDescription: 'ARM -- Mali-400 MP -- OpenGL ES 2.0 -- Model: SCH-I605, Product: t0ltevzw, Manufacturer: samsung, Hardware: smdk4x12'
GL Layers! EGL? EGL+ GL Context? GL Context+ GL Layers+ 
samsung SCH-I605
Verizon/t0ltevzw/t0ltevzw:4.1.2/JZO54K/I605VRAMC3:user/release-keys

Crashing Thread
Frame 	Module 	Signature 	Source
0 	libxul.so 	mozilla::DecoderTraits::CanHandleMediaType(char const*, bool, nsAString_internal const&) 	content/media/DecoderTraits.cpp
1 	libxul.so 	mozilla::dom::HTMLMediaElement::GetCanPlay(nsAString_internal const&) 	content/html/content/src/HTMLMediaElement.cpp
2 	libxul.so 	mozilla::dom::HTMLMediaElement::CanPlayType(nsAString_internal const&, nsAString_internal&) 	content/html/content/src/HTMLMediaElement.cpp
3 	libxul.so 	mozilla::dom::HTMLMediaElementBinding::canPlayType 	obj-firefox/dom/bindings/HTMLMediaElementBinding.cpp
4 	libxul.so 	mozilla::dom::HTMLMediaElementBinding::genericMethod 	obj-firefox/dom/bindings/HTMLMediaElementBinding.cpp
5 	libxul.so 	js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) 	js/src/jscntxtinlines.h
6 	libxul.so 	Interpret 	js/src/vm/Interpreter.cpp
7 	libxul.so 	js::RunScript(JSContext*, js::RunState&) 	js/src/vm/Interpreter.cpp
8 	libxul.so 	js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) 	js/src/vm/Interpreter.cpp
9 	libxul.so 	js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>) 	js/src/vm/Interpreter.cpp
10 	libxul.so 	js::ion::DoCallFallback 	js/src/ion/BaselineIC.cpp
11 		@0x594e9aae

More reports at:
https://crash-stats.mozilla.com/report/list?product=FennecAndroid&signature=mozilla%3A%3ADecoderTraits%3A%3ACanHandleMediaType%28char+const*%2C+bool%2C+nsAString_internal+const%26%29

Comment 1

[Chris Pearce [:cpearce (GMT+13)]]

Is this a null pointer deref? I guess |codecs| is null in mozilla::DecoderTraits::CanHandleMediaType?

Comment 2

[Scoobidiver (away)]

More reports also at:
https://crash-stats.mozilla.com/report/list?product=FennecAndroid&signature=%400x0+|+mozilla%3A%3ADecoderTraits%3A%3ACanHandleMediaType%28char+const*%2C+bool%2C+nsAString_internal+const%26%29

Comment 3

[Scoobidiver (away)]

Reports also at:
https://crash-stats.mozilla.com/report/list?product=FennecAndroid&signature=nsAString_internal%3A%3AEqualsASCII%28char+const*%29+const

Comment 4

[Scoobidiver (away)]

Reports also at:
https://crash-stats.mozilla.com/report/list?product=FennecAndroid&signature=libomxplugin.so+%28deleted%29%400x111e
https://crash-stats.mozilla.com/report/list?product=FennecAndroid&signature=libomxplugin.so+%28deleted%29%400x117b
https://crash-stats.mozilla.com/report/list?product=FennecAndroid&signature=libomxplugin.so+%28deleted%29%400x1120

Comment 5

[Scoobidiver (away)]

With combined signatures, it's #2 crasher in 24.0b1 and #20 in 26.0a1.

Comment 6

[Gian-Carlo Pascutto [:gcp]]

>Is this a null pointer deref? I guess |codecs| is null in mozilla::DecoderTraits::CanHandleMediaType?

Seems reasonable in light of the various signatures all involving that.

Comment 7

[Gian-Carlo Pascutto [:gcp]]

After reading a bit more code I'm not so sure of that any more :P

Setting STR wanted, if this is a topcrasher hopefully that ain't so hard?

Comment 8

[bhavana bajaj [:bajaj]]

:Kairo/:kbrosnan,

Any device/OS correlation or urls that may help QA here?

Comment 9

[Tracy Walker [:tracy]]

there are no url's associated with this signature

Comment 10

[Gian-Carlo Pascutto [:gcp]]

Can someone (cpearce?) explain in what circumstances exactly this code path is taken? I'd sortof have assummed that a simple video would pass through here, for example this page:
http://people.mozilla.com/~dclarke/b.html

But it doesn't seem to.

Comment 11

[:ehsan akhgari]

Looking at the code, it looks like this code can be triggered for HTML media elements with multiple <source> child nodes, each specifying a type attribute.  Look up HTMLMediaElement::GetCanPlay.

Comment 12

[Chris Pearce [:cpearce (GMT+13)]]

Based on the stack in comment 0 javascript is calling HTMLMediaElement.canPlayType().

i.e.:
<script>
document.createElement("video").canPlayType("video/mp4");
</script>

Comment 13

[Gian-Carlo Pascutto [:gcp]]

I don't really see any way for these crashes to be caused in our code. The codecs thing being null isn't it, the thing that's being passed is the address of a pointer variable that's on the stack, so that'll always be valid. MIMEType is used a bunch of times before and wrapped in an nsDependentCString, so that being the cause of the crash there would be really strange. 

GetMediaPluginHost() also can't fail. That leaves FindDecoder, which doesn't do anything that should fail either until the plugin->CanDecode call, which is resolved dynamically in libomxplugin. That only does a bunch of strncmp, so it can only fail if MIMEType is busted again - which just isn't likely.

OmxPlugin is dangerously close to code that interfaces with vendor specific code, so device correlations would be good here.

One strange thing about the code in DecoderTraits::CanHandleMediaType is that it keeps going on even if it has already found a decoder. i.e. it checks the MimeType for things it can decode, if so, adjusts codecs, but then repeats this for all decoders and potentially setting/resetting (instead of adding) decoders multiple times. This won't cause the crash, but it looks strange and inefficient.

Comment 14

[cajbir (:cajbir)]

At a guess there's some string that passed to 'canPlayType' on Android that's causing the crash. A test case that enumerates lots of valid/invalid mimetypes while calling canPlayType might find it.

Comment 15

[Gian-Carlo Pascutto [:gcp]]

Does OEM vendor code override ours in:
http://dxr.mozilla.org/mozilla-central/source/media/omx-plugin/OmxPlugin.cpp#l1028
?

I thought not, i.e. that the vendor specific code is actually called by OmxPlugin. I can't see how the above function can go wrong due to specific strings.

Comment 16

[Alex Keybl [:akeybl]]

gcp - can you provide a script for QA to test doublec's comment 14? Or is it not worthwhile?

Comment 17

[Gian-Carlo Pascutto [:gcp]]

The CanDecode function is here:
http://dxr.mozilla.org/mozilla-central/source/media/omx-plugin/OmxPlugin.cpp#l905

I don't see how this can crash vs. an arbitrary mimetype so doublec's comment makes no sense to me. Futhermore, some of the crash reports have a SIGILL error, which also can't be caused by anything like that. My best guess is that this is going wrong, but I don't know why:
http://dxr.mozilla.org/mozilla-central/source/content/media/plugins/MediaPluginHost.cpp#l211

Comment 18

[cajbir (:cajbir)]

(In reply to Gian-Carlo Pascutto (:gcp) from comment #17)
> The CanDecode function is here:
> http://dxr.mozilla.org/mozilla-central/source/media/omx-plugin/OmxPlugin.
> cpp#l905

What's pointing to the OMX Plugin code? The crash could be in the other code in CanHandleMediaType can't it?

Comment 19

[cajbir (:cajbir)]

(In reply to Chris Double (:doublec) from comment #18)
>
> What's pointing to the OMX Plugin code? The crash could be in the other code
> in CanHandleMediaType can't it?

Ah, I see some of the crash reports have more data in the stack trace: https://crash-stats.mozilla.com/report/index/fbfc31e0-0ddd-45e4-a731-0cb202130903

0 	libomxplugin.so (deleted) 	libomxplugin.so (deleted)@0x111e 	
1 	libxul.so 	mozilla::MediaPluginHost::FindDecoder(nsACString_internal const&, char const* const**) 	content/media/plugins/MediaPluginHost.cpp
2 	libxul.so 	mozilla::DecoderTraits::CanHandleMediaType(char const*, bool, nsAString_internal const&) 	content/media/DecoderTraits.cpp
3 	libxul.so 	mozilla::DecoderTraits::ShouldHandleMediaType(char const*) 	content/media/DecoderTraits.cpp
4 	libxul.so 	nsContentDLF::CreateInstance(char const*, nsIChannel*, nsILoadGroup*, char const*, nsISupports*, nsISupports*, nsIStreamListener**, nsIContentViewer**) 	layout/build/nsContentDLF.cpp
5 	libxul.so 	nsDocShell::NewContentViewerObj(char const*, nsIRequest*, nsILoadGroup*, nsIStreamListener**, nsIContentViewer**) 	docshell/base/nsDocShell.cpp
6 	libxul.so 	nsDocShell::CreateContentViewer(char const*, nsIRequest*, nsIStreamListener**) 	docshell/base/nsDocShell.cpp
7 	libxul.so 	nsDSURIContentListener::DoContent(char const*, bool, nsIRequest*, nsIStreamListener**, bool*) 	docshell/base/nsDSURIContentListener.cpp
8 	libxul.so 	nsDocumentOpenInfo::TryContentListener(nsIURIContentListener*, nsIChannel*) 	uriloader/base/nsURILoader.cpp
9 	libxul.so 	nsDocumentOpenInfo::DispatchContent(nsIRequest*, nsISupports*) 	uriloader/base/nsURILoader.cpp
10 	libxul.so 	nsDocumentOpenInfo::OnStartRequest(nsIRequest*, nsISupports*)

Interesting that that stack trace doesn't involve CanPlayType JS call at all whereas comment 0 does.

Comment 20

[cajbir (:cajbir)]

What does the (dead/deleted) mean in the stack crash line:

0 	libomxplugin.so (deleted) 	libomxplugin.so (deleted)@0x111e 

The crashes seem to happen on beta - do any instances happen on Aurora or Nightly?

Looking at the symbols for libomxplugin.so on beta, I see the following:

  FUNC 1110 60 0 OmxPlugin::CanDecode
  1110 2 990 0
  1112 2 990 0
  1114 2 976 0
  1116 2 990 0
  1118 2 976 0
  111a 2 990 0
  111c 6 976 0
  1122 2 991 0

So 111e is around line 976 in OmxPlugin.cpp which is:

  static bool Match(const char *aMimeChars, size_t aMimeLen, const char *aNeedle)
  {
    return !strncmp(aMimeChars, aNeedle, aMimeLen);      <-- 976
  }

Disassembling the CanDecode function in beta's libomxplugin.so shows:

  0000110e <.text+0x146>:
    110e:       0000            movs    r0, r0
    1110:       b570            push    {r4, r5, r6, lr}
    1112:       460c            mov     r4, r1
    1114:       4911            ldr     r1, [pc, #68]   ; (115c <_ZNK7android10DataSource11getMIMETypeEv@plt+0x1a0>)
    1116:       4616            mov     r6, r2
    1118:       4622            mov     r2, r4
    111a:       4605            mov     r5, r0
    111c:       4479            add     r1, pc
    111e:       f7ff ee82       blx     e24 <__wrap_strncmp@plt>
    1122:       b1b0            cbz     r0, 1152 <_ZNK7android10DataSource11getMIMETypeEv@plt+0x196>
    1124:       490e            ldr     r1, [pc, #56]   ; (1160 <_ZNK7android10DataSource11getMIMETypeEv@plt+0x1a4>)
    1126:       4628            mov     r0, r5
    1128:       4622            mov     r2, r4
    112a:       4479            add     r1, pc
    112c:       f7ff ee7a       blx     e24 <__wrap_strncmp@plt>

Here 111e looks to be the call to strncmp. The strncmp arguments are aMimeChars, aNeedle, and aMimeLen. aNeedle is a static string so should be ok. So either aMimeChars or aMimeLen is likely to be invalid. Tracing back through the code aMimeLen seems to come from a strlen call on aMimeChars, which is a UTF8 string. aMimeChars itself is the char* pointer from a nsCDependentString allocated on the stack as a temporary DecoderTraits.cpp line 359:

  GetMediaPluginHost()->FindDecoder(nsDependentCString(aMIMEType), &codecList))

This should be fine though. One thing Anthony Jones pointed out is that The calls to Match (which calls the strncmp) in OmxDecoder.cpp seem to be incorrect:

 if (!Match(aMimeChars, aMimeLen, "video/mp4") &&
      !Match(aMimeChars, aMimeLen, "audio/mp4") &&
      !Match(aMimeChars, aMimeLen, "audio/mpeg") &&
      !Match(aMimeChars, aMimeLen, "application/octet-stream")) { // file urls
    return false;
  }

If 'aMimeChars' is an empty string, then aMimeLen will be zero and the strncmp will return true. It will also match for aMimeChars being any shorter substring of the needle. Match should use strcmp. I can't see this causing the crash but it should be fixed.

My suggestion for continuing here would be:

1) Fix the match/strncmp bug.
2) Fix the mochitest that should have detected that bug.
3) Add some logging that logs aMimeChars.
4) Write a fuzzer that stresses this code path to see of there's some combination of string that in aMimeChars causing the crash, or if there is some memory issue causing an invalid string pointer or string length due to destruction of objects that appears after repeated page loads, refreshes, etc. Make sure this fuzzer exercises unicode characters.

It would also be useful to obtain somehow:

1) The answer to what dead/deleted means as mentioned earlier
2) Can the crash report show addresses of the arguments to the functions
3) We need URLs for the crashes.

Comment 21

[Robert Kaiser]

(In reply to Chris Double (:doublec) from comment #20)
> 1) The answer to what dead/deleted means as mentioned earlier
> 2) Can the crash report show addresses of the arguments to the functions

Benjamin, can you help with those?

> 3) We need URLs for the crashes.

Added needURLs keyword so our QA people will pick that up and provide URLs.

Comment 22

[Gian-Carlo Pascutto [:gcp]]

https://crash-stats.mozilla.com/report/index/0b89e457-af27-466a-bd25-e90ec2130917

This new report seems to say trying to play videos on YouTube can trigger it. So maybe logging what's happening on these functions while browsing YouTube gives us some clue.

They are crashing with a SIGILL on:
111e:       f7ff ee82       blx     e24 <__wrap_strncmp@plt>

Is this issue related to transitioning from Thumb to ARM combined with our dynamic loading of this library?

Comment 23

[Benjamin Smedberg]

dead/deleted often means that the .so was unloaded. On android we see that sometimes for sharedlibs which are loaded, so I'm not sure what's going on with that. But certainly if you have any code which might unload that lib, you should probably stop doing that.

The crash report contains stack memory and the register state at the time of the crash. If parameters are contained on the stack or in registers, then you should be able to extract them, but there isn't an easy automated tool for that.

If you'd like to try debugging in gdb, there is a tool which will convert a minidump to a core file. Trying to find links to it; ted knows but all I could find right now is http://www.chromium.org/chromium-os/how-tos-and-troubleshooting/crash-reporting/debugging-a-minidump#TOC-Generate-core-file and see http://code.google.com/p/google-breakpad/source/browse/#svn%2Ftrunk%2Fsrc%2Ftools%2Flinux%2Fmd2core

We also have or could easily have a tool which just dumps memory in hex and you could disassemble by hand. I'm sorry our tooling for Android isn't great currently.

Comment 24

[(not currently active) Ted Mielczarek]

The Breakpad code gets its list of shared libraries directly from /proc/self/maps, so the (deleted) comes from there. That simply means that the file in question has been unlinked.

Comment 25

[Gian-Carlo Pascutto [:gcp]]

What's the meaning of this wrt our Android linker right now? As far as I know we don't actually ever unzip those libs from the APK? So why is libxul OK in those traces but libomxplugin isn't?

Comment 26

[Gian-Carlo Pascutto [:gcp]]

When trying to debug and see these codepaths in action, I'm crashing with this:

0x7f0132e8 in nsQueryInterface::operator() (this=0x74f32df8, aIID=..., answer=0x74f32e04)
    at /home/morbo/hg/mozilla-central/xpcom/glue/nsCOMPtr.cpp:14
14					status = mRawPtr->QueryInterface(aIID, answer);
(gdb) bt
#0  0x7f0132e8 in nsQueryInterface::operator() (this=0x74f32df8, aIID=..., answer=0x74f32e04)
    at /home/morbo/hg/mozilla-central/xpcom/glue/nsCOMPtr.cpp:14
#1  0x7e0d85c6 in nsCOMPtr<mozilla::GetIntPrefEvent>::assign_from_qi (this=0x1, qi=..., aIID=...)
    at ../../../dist/include/nsCOMPtr.h:1199
#2  0x7e0d8004 in nsCOMPtr<mozilla::GetIntPrefEvent>::nsCOMPtr (this=0x74f33000, qi=...) at ../../../dist/include/nsCOMPtr.h:588
#3  0x74f32ed4 in ?? ()
#4  0x74f32ed4 in ?? ()

This seems to be:
http://dxr.mozilla.org/mozilla-central/source/content/media/plugins/MediaPluginHost.cpp#l60

The relation to the current crash stacks is that this function is appended to the stuff that's loaded from OmxPlugin:
http://dxr.mozilla.org/mozilla-central/source/content/media/plugins/MediaPluginHost.cpp#l70
versus:
http://dxr.mozilla.org/mozilla-central/source/content/media/plugins/MPAPI.h#l132
http://dxr.mozilla.org/mozilla-central/source/content/media/omx/MPAPI.h#l122

I wonder if this is MediaDecoder::IsMediaPluginsEnabled() despite the int vs bool mismatch:
http://dxr.mozilla.org/mozilla-central/source/content/media/DecoderTraits.cpp#l416

Stepping through the calls makes a whole lot of things that don't make any sense show up, so I'm not sure what to make of this :(

Comment 27

[Gian-Carlo Pascutto [:gcp]]

I think I'm getting closer. Something is probably calling
http://dxr.mozilla.org/mozilla-central/source/content/media/plugins/MediaPluginHost.cpp#l301
which destructs the singleton instance all these functions are operating on.

Unfortunately putting a breakpoint there doesn't show a usable calling stack.

Comment 28

[Mike Hommey [:glandium]]

FWIW, my guess for the (deleted) is that the crash reporter is not using the data the linker is providiving to it for that library and uses /proc/self/maps instead. Might have to do with the lib being loaded after the crash reporter is initialized. That'd be a bug to file in itself, because if a lib is elfhacked (which omxplugin is not, fortunately) it means the symbols would be wrong.

Comment 29

[Kevin Brosnan [:kbrosnan]]

Looked again and still no usable URLs also mentioned in comment 9.

Comment 30

[Gian-Carlo Pascutto [:gcp]]

If I make a m-c -O0 debug build, and try html5test.com, then I'm blowing up as soon as I call GetMediaPluginHost(). I don't even get to the constructor before some assertions hit. Unfortunately this seems to suggest that we're already hosed by the time we hit CanHandleMediaType (I ifdeffed out all other formats for debugging), or there's something that makes
http://dxr.mozilla.org/mozilla-central/source/content/media/plugins/MediaPluginHost.cpp#l296
explode in a spectacular manner.

Comment 31

[Gian-Carlo Pascutto [:gcp]]

I did some joint debugging with Jim Chen today and we found that the Android debugger gets really confused by the on-demand decompressing linker, particularly if you try to put a breakpoint in code that hasn't executed yet. So comment 26 and on are a red herring.

Comment 32

[Kyle Wooten]

Thanks!

Comment 33

[Gian-Carlo Pascutto [:gcp]]

Believed to be fixed by bug 902431 so mirroring flags.

Comment 34

[Gian-Carlo Pascutto [:gcp]]

Ugh, wrong bug. Sorry about that.

Comment 35

[Alex Keybl [:akeybl]]

(In reply to Gian-Carlo Pascutto (:gcp) from comment #31)
> I did some joint debugging with Jim Chen today and we found that the Android
> debugger gets really confused by the on-demand decompressing linker,
> particularly if you try to put a breakpoint in code that hasn't executed
> yet. So comment 26 and on are a red herring.

What next steps would you like to pursue? How can QA or the stability team help in your investigation? Given the lack of crash URLs, can you direct QA's testing time in a different fashion?

Comment 36

[Gian-Carlo Pascutto [:gcp]]

Reports from 26 and 27:
https://crash-stats.mozilla.com/report/index/de0cdc77-a08b-4064-8111-a0e692131010
https://crash-stats.mozilla.com/report/index/2b96ecfb-a757-45c3-aa1e-71da92131013

The latter is interesting because that code seems to run before the entire libomxplugin stuff, which points to aMIMEType or the memory near it being busted before we get here.

Comment 37

[Randell Jesup [:jesup] (needinfo me)]

Could this be related to bug 890985?  (i.e. an alignment issue?)  Jim?

Comment 38

[Benjamin Smedberg]

I doubt it. Those misalignment crashes are SIGBUS and this is SIGSEGV.

Comment 39

[Gian-Carlo Pascutto [:gcp]]

>Those misalignment crashes are SIGBUS and this is SIGSEGV.

SIGILL in many cases, actually.

Comment 40

[Gian-Carlo Pascutto [:gcp]]

I'm working on the fuzzer. It found that Firefox claims it can "probably" play "audio/webm".

At least I already know that wasn't for nothing...

Comment 41

[Gian-Carlo Pascutto [:gcp]]

Attachment: canPlayType fuzzer

Here's a fuzzer for canPlayType, which constructs a fuzzed string by taking the separate parts of a legal one and fuzzing them separately, leaving good enough odds that the string looks like something legal to the relevant code.

Comment 42

[Gian-Carlo Pascutto [:gcp]]

Filed follow-up Bug 927462 and Bug 927474 for the string matching issues, which don't explain this bug so far. Filed Bug 927480 for the broken crash reporting, which might help a little here.

QA, we know there's no (specific) URLs involved here, but do we have an overview of device frequency?

A stat like this: https://bugzilla.mozilla.org/show_bug.cgi?id=890985#c7  could potentially help to see where our odds of triggering it are best.

In theory you can visit the attached fuzzer to exercise this code (it'll run forever once you click), and see if some dorking around on random websites doesn't make it crash.

Comment 43

[Kevin Brosnan [:kbrosnan]]

You can view this data by loading the signature summary and scrolling down to the Mobile Devices section and expand that. There is also GPU data.

https://crash-stats.mozilla.com/report/list?signature=%400x0+|+mozilla%3A%3ADecoderTraits%3A%3ACanHandleMediaType%28char+const*%2C+bool%2C+nsAString_internal+const%26%29&product=FennecAndroid&query_type=contains&range_unit=weeks&process_type=any&hang_type=any&date=2013-10-16+17%3A00%3A00&range_value=2

asus	 	Nexus 7		18 (REL) 	9
samsung 	GT-N7100	16 (REL) 	6
samsung 	GT-I9300	16 (REL) 	5
samsung 	GT-N8000	16 (REL) 	5
samsung 	GT-I9300	18 (REL) 	3
samsung 	GT-N8010	16 (REL) 	3
samsung 	GT-N5100	17 (REL) 	3
samsung 	GT-P3100	15 (REL) 	2
samsung 	GT-I9100	16 (REL) 	2
samsung 	SCH-I605	16 (REL) 	2 

https://crash-stats.mozilla.com/report/list?signature=mozilla%3A%3ADecoderTraits%3A%3ACanHandleMediaType%28char+const*%2C+bool%2C+nsAString_internal+const%26%29&product=FennecAndroid&query_type=contains&range_unit=weeks&process_type=any&hang_type=any&date=2013-10-16+17%3A00%3A00&range_value=2

samsung 	GT-N7100	16 (REL) 	5
samsung 	GT-N8010	16 (REL) 	3
samsung 	GT-N8000	16 (REL) 	2
samsung 	Galaxy Nexus	17 (REL) 	2
samsung 	SHV-E250L	16 (REL) 	1
samsung 	GT-I9152	17 (REL) 	1
samsung 	GT-I9305	16 (REL) 	1
asus 		ME301T		17 (REL) 	1 

Mfg.            Model           API Ver      # Crashes

Comment 44

[Brad Lassey [:blassey] (use needinfo?)]

This looks like #74 in Beta, #171 in Aurora and there are no crashes with this signature in nightly. Re-nom'ing to untrack.

Comment 45

[Tracy Walker [:tracy]]

this no longer a topcrasher.

Comment 46

[Ryan VanderMeulen [:RyanVM]]

Still a low-volume crasher AFAICT, but finding a useful regression range at this point seems pretty unlikely.

Comment 47

[Sylvestre Ledru [:Sylvestre]]

Closing because no crash reported since 12 weeks.