Closed
Bug 898767
Opened 10 years ago
Closed 4 years ago
crash in mozilla::DecoderTraits::CanHandleMediaType
Categories
(Core :: Audio/Video: Playback, defect, P2)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: scoobidiver, Assigned: gcp)
Details
(Keywords: crash, regression, Whiteboard: [native-crash])
Crash Data
Attachments
(1 file)
5.67 KB,
text/html
|
Details |
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•10 years ago
|
||
Is this a null pointer deref? I guess |codecs| is null in mozilla::DecoderTraits::CanHandleMediaType?
Reporter | ||
Comment 2•10 years ago
|
||
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
Crash Signature: [@ mozilla::DecoderTraits::CanHandleMediaType(char const*, bool, nsAString_internal const&)] → [@ mozilla::DecoderTraits::CanHandleMediaType(char const*, bool, nsAString_internal const&)]
[@ @0x0 | mozilla::DecoderTraits::CanHandleMediaType(char const*, bool, nsAString_internal const&)]
status-firefox23:
--- → unaffected
Version: 25 Branch → 24 Branch
Reporter | ||
Comment 3•10 years ago
|
||
Reports also at: https://crash-stats.mozilla.com/report/list?product=FennecAndroid&signature=nsAString_internal%3A%3AEqualsASCII%28char+const*%29+const
Crash Signature: [@ mozilla::DecoderTraits::CanHandleMediaType(char const*, bool, nsAString_internal const&)]
[@ @0x0 | mozilla::DecoderTraits::CanHandleMediaType(char const*, bool, nsAString_internal const&)] → [@ mozilla::DecoderTraits::CanHandleMediaType(char const*, bool, nsAString_internal const&)]
[@ @0x0 | mozilla::DecoderTraits::CanHandleMediaType(char const*, bool, nsAString_internal const&)]
[@ nsAString_internal::EqualsASCII(char const*) const ]
status-firefox26:
--- → affected
Reporter | ||
Comment 4•10 years ago
|
||
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
Crash Signature: [@ mozilla::DecoderTraits::CanHandleMediaType(char const*, bool, nsAString_internal const&)]
[@ @0x0 | mozilla::DecoderTraits::CanHandleMediaType(char const*, bool, nsAString_internal const&)]
[@ nsAString_internal::EqualsASCII(char const*) const ] → [@ mozilla::DecoderTraits::CanHandleMediaType(char const*, bool, nsAString_internal const&)]
[@ @0x0 | mozilla::DecoderTraits::CanHandleMediaType(char const*, bool, nsAString_internal const&)]
[@ nsAString_internal::EqualsASCII(char const*) const ]
[@ …
Reporter | ||
Comment 5•10 years ago
|
||
With combined signatures, it's #2 crasher in 24.0b1 and #20 in 26.0a1.
Updated•10 years ago
|
Assignee: nobody → gpascutto
tracking-fennec: ? → 24+
Updated•10 years ago
|
Assignee | ||
Comment 6•10 years ago
|
||
>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.
Assignee | ||
Comment 7•10 years ago
|
||
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?
Keywords: steps-wanted
Comment 8•10 years ago
|
||
:Kairo/:kbrosnan, Any device/OS correlation or urls that may help QA here?
Assignee | ||
Comment 10•10 years ago
|
||
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.
Flags: needinfo?(cpearce)
Comment 11•10 years ago
|
||
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•10 years ago
|
||
Based on the stack in comment 0 javascript is calling HTMLMediaElement.canPlayType(). i.e.: <script> document.createElement("video").canPlayType("video/mp4"); </script>
Flags: needinfo?(cpearce)
Updated•10 years ago
|
Keywords: regressionwindow-wanted
Assignee | ||
Comment 13•10 years ago
|
||
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•10 years ago
|
||
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.
Assignee | ||
Comment 15•10 years ago
|
||
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•10 years ago
|
||
gcp - can you provide a script for QA to test doublec's comment 14? Or is it not worthwhile?
Flags: needinfo?(gpascutto)
Assignee | ||
Comment 17•10 years ago
|
||
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
Flags: needinfo?(gpascutto)
Comment 18•10 years ago
|
||
(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•10 years ago
|
||
(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.
Updated•10 years ago
|
tracking-firefox25:
--- → ?
Updated•10 years ago
|
Comment 20•10 years ago
|
||
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•10 years ago
|
||
(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.
Keywords: needURLs
Assignee | ||
Comment 22•10 years ago
|
||
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•10 years ago
|
||
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•10 years ago
|
||
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.
Assignee | ||
Comment 25•10 years ago
|
||
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?
Assignee | ||
Comment 26•10 years ago
|
||
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 :(
Assignee | ||
Comment 27•10 years ago
|
||
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•10 years ago
|
||
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•10 years ago
|
||
Looked again and still no usable URLs also mentioned in comment 9.
Keywords: needURLs
Assignee | ||
Comment 30•10 years ago
|
||
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.
Assignee | ||
Comment 31•10 years ago
|
||
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•10 years ago
|
||
Thanks!
Assignee | ||
Comment 33•10 years ago
|
||
Believed to be fixed by bug 902431 so mirroring flags.
Assignee | ||
Comment 34•10 years ago
|
||
Ugh, wrong bug. Sorry about that.
Comment 35•10 years ago
|
||
(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?
Updated•10 years ago
|
Flags: needinfo?(gpascutto)
Assignee | ||
Comment 36•9 years ago
|
||
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•9 years ago
|
||
Could this be related to bug 890985? (i.e. an alignment issue?) Jim?
Flags: needinfo?(nchen)
Comment 38•9 years ago
|
||
I doubt it. Those misalignment crashes are SIGBUS and this is SIGSEGV.
Flags: needinfo?(nchen)
Assignee | ||
Comment 39•9 years ago
|
||
>Those misalignment crashes are SIGBUS and this is SIGSEGV.
SIGILL in many cases, actually.
Flags: needinfo?(gpascutto)
Assignee | ||
Comment 40•9 years ago
|
||
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...
Assignee | ||
Comment 41•9 years ago
|
||
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.
Assignee | ||
Comment 42•9 years ago
|
||
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.
Flags: needinfo?(kbrosnan)
Comment 43•9 years ago
|
||
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
Flags: needinfo?(kbrosnan)
Comment 44•9 years ago
|
||
This looks like #74 in Beta, #171 in Aurora and there are no crashes with this signature in nightly. Re-nom'ing to untrack.
Updated•9 years ago
|
tracking-fennec: ? → -
Updated•9 years ago
|
Updated•7 years ago
|
Crash Signature: , nsAString_internal const&)]
[@ nsAString_internal::EqualsASCII(char const*) const ]
[@ libomxplugin.so (deleted)@0x111e ]
[@ libomxplugin.so (deleted)@0x117b ]
[@ libomxplugin.so (deleted)@0x1120 ] → , nsAString_internal const&)]
[@ nsAString_internal::EqualsASCII(char const*) const ]
[@ libomxplugin.so (deleted)@0x111e ]
[@ libomxplugin.so (deleted)@0x117b ]
[@ libomxplugin.so (deleted)@0x1120 ]
[@ mozilla::DecoderTraits::CanHandleMediaType]
[@…
Comment 46•7 years ago
|
||
Still a low-volume crasher AFAICT, but finding a useful regression range at this point seems pretty unlikely.
Keywords: regressionwindow-wanted
Updated•7 years ago
|
Component: Audio/Video → Audio/Video: Playback
Updated•5 years ago
|
Rank: 15
Priority: -- → P2
Comment 47•4 years ago
|
||
Closing because no crash reported since 12 weeks.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
Comment 48•2 months ago
|
||
Removing steps-wanted
keyword because this bug has been resolved.
Keywords: steps-wanted
You need to log in
before you can comment on or make changes to this bug.
Description
•