With combined signatures, it's #5 top crasher in the first day of 20.0b1. It occurs on: * Samsung SGH-T989 = Galaxy SII * Samsung SGH-I717 = Galaxy Note * Samsung SGH-I727 = Galaxy SII Signature libstagefright.so@0x160f61 More Reports Search UUID c86e514b-98ab-4c4c-8686-aa0b02130227 Date Processed 2013-02-27 04:29:14 Uptime 17 Last Crash 25 seconds before submission Install Age 10.8 hours since version was first installed. Install Time 2013-02-26 17:38:39 Product FennecAndroid Version 20.0 Build ID 20130222123731 Release Channel beta OS Android OS Version 0.0.0 Linux 3.0.8-perf-1190554 #1 SMP PREEMPT Mon Jan 14 23:03:19 KST 2013 armv7l samsung/SGH-T989/SGH-T989:4.0.4/IMM76D/UVLI4:user/release-keys Build Architecture arm Build Architecture Info Crash Reason SIGSEGV Crash Address 0xdeadbaad App Notes AdapterDescription: 'Qualcomm -- Adreno (TM) 220 -- OpenGL ES 2.0 2184622 -- Model: SGH-T989, Product: SGH-T989, Manufacturer: samsung, Hardware: qcom' EGL? EGL+ GL Context? GL Context+ GL Layers? GL Layers+ Stagefright? Stagefright+ samsung SGH-T989 samsung/SGH-T989/SGH-T989:4.0.4/IMM76D/UVLI4:user/release-keys Processor Notes sp-processor09.phx1.mozilla.com_9484:2008; exploitablity tool: ERROR: unable to analyze dump EMCheckCompatibility True Adapter Vendor ID Qualcomm Adapter Device ID Adreno (TM) 220 Device samsung SGH-T989 Android API Version 15 (REL) Android CPU ABI armeabi-v7a Frame Module Signature Source 0 libc.so libc.so@0x17d18 1 libstagefright.so libstagefright.so@0x160f61 2 libstagefright.so libstagefright.so@0x160f61 3 libstagefright.so libstagefright.so@0x160f61 4 libcutils.so libcutils.so@0x3f3f 5 libxul.so _cairo_gstate_init gfx/cairo/cairo/src/cairo-gstate.c:102 6 @0x6e6f6971 7 OMXCodec (deleted) OMXCodec @0x4aa21f 8 libbinder.so libbinder.so@0x20165 9 libbinder.so libbinder.so@0x1b825 10 libbinder.so libbinder.so@0x1bba1 11 libnativehelper.so TimeZones_getZoneStringsImpl libcore_icu_TimeZones.cpp:204 12 libutils.so libutils.so@0x19f2b ... 49 libc.so libc.so@0x129ce 50 libmozglue.so arena_dalloc memory/mozjemalloc/jemalloc.c:4667 51 libxul.so mozilla::layers::ImageContainerChild::AllocUnsafeShmemSync ReentrantMonitor.h:59 52 libstagefright.so libstagefright.so@0xa3941 53 libstagefright.so libstagefright.so@0x160f70 54 OMXCodec (deleted) OMXCodec @0x3ffffe 55 @0x6893dffe 56 libomxplugin.so OmxPlugin::OmxDecoder::ToVideoFrame_ColorConverter media/omx-plugin/OmxPlugin.cpp:739 57 libomxplugin.so OmxPlugin::OmxDecoder::ToVideoFrame media/omx-plugin/OmxPlugin.cpp:774 58 libomxplugin.so OmxPlugin::OmxDecoder::ReadVideo media/omx-plugin/OmxPlugin.cpp:831 59 libxul.so mozilla::MediaPluginReader::DecodeVideoFrame content/media/plugins/MediaPluginReader.cpp:138 60 libxul.so mozilla::MediaDecoderReader::DecodeToFirstVideoData content/media/MediaDecoderReader.cpp:377 61 libxul.so mozilla::MediaDecoderReader::FindStartTime content/media/MediaDecoderReader.cpp:411 62 libxul.so mozilla::MediaDecoderStateMachine::FindStartTime content/media/MediaDecoderStateMachine.cpp:2456 63 libxul.so mozilla::MediaDecoderStateMachine::DecodeMetadata content/media/MediaDecoderStateMachine.cpp:1799 64 libxul.so mozilla::MediaDecoderStateMachine::DecodeThreadRun content/media/MediaDecoderStateMachine.cpp:477 65 libxul.so nsRunnableMethodImpl<tag_nsresult 66 libxul.so nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:627 67 libxul.so NS_ProcessNextEvent_P obj-firefox/xpcom/build/nsThreadUtils.cpp:238 68 libxul.so nsThread::ThreadFunc xpcom/threads/nsThread.cpp:265 69 libnspr4.so _pt_root nsprpub/pr/src/pthreads/ptthread.c:156 70 libc.so libc.so@0x1327e 71 libc.so libc.so@0x12dd2 More reports at: https://crash-stats.mozilla.com/query/query?product=FennecAndroid&query_search=signature&query_type=contains&query=libstagefright.so%400x16&do_query=1

(In reply to Scoobidiver from comment #0) > It occurs on: > * Samsung SGH-T989 = Galaxy SII > * Samsung SGH-I717 = Galaxy Note > * Samsung SGH-I727 = Galaxy SII Just a note that these appear to be the qualcom chipset variants of the S2 and Note (US only?), not the Exynos chipsets verisions (available in NZ and internationally). This may affect ability to reproduce if people are trying the different chipset.

With combined signatures, it's #5 top crasher in 20.0b2 and #7 in 21.0a2.

Given comment 1, kbrosnan will be in the best position to try to repro. Would also be great to get clarification around whether we actually believe this is a single issue, or just a bucket. Chris?

(In reply to Alex Keybl [:akeybl] from comment #3) > Would also be great to get clarification around whether we actually believe > this is a single issue, or just a bucket. Chris? It's not possible to know without being able to reproduce and investigate, sorry.

A few select URLs: 2 http://www.canon.com/news/2013/mar04e.html 1 http://www.nationalpost.com/m/wp/news/canada/blog.html?b=news.nationalpost.com/2013/03/08/quebec-language-protection-head-resigning-in-wake-of-pastagate 1 http://m.accuweather.com/en/weather-video/breaking-weather-snowy-dakotas/1670024 1 http://www.androidfap.net/phone/#_video 2 http://m.usatoday.com/article/news/1963935 1 http://abcnews.go.com/US/wireStory/splashy-ads-tackle-lawsuit-watery-beer-186436

No luck on any of those URLs using the non-Qualcomm variant devices (SII/Note). This seems specific to those Samsung variants.

(In reply to Aaron Train [:aaronmt] from comment #6) > No luck on any of those URLs using the non-Qualcomm variant devices > (SII/Note). This seems specific to those Samsung variants. Do we have qcom variant devices to try on? I was under the impression that Kevin did have such a device. If we can get this repro'd on a qcom chipset then that can be handed off to Chris for further investigation.

Nope. We ordered an North American SIII but that was shipped to Chris Double before I could look at it.

(In reply to Kevin Brosnan [:kbrosnan] from comment #8) > Nope. We ordered an North American SIII but that was shipped to Chris Double > before I could look at it. That was running Jellybean and there is a reproducible crash (bug 812881) that it's being used to create a fix for.

Checked trunk and Beta on DeviceAnywere using their i727 and i717 unfortunately their phones are running Android 2.3. Was able to get STR for bug 766816. Placed order with Desktop for a SII that meets the requirements for this bug. REQ0014187

Looks like this is going to be a miss for FF20, wontfixing.

Kevin - have you received the device now? Any progress?

I have not. Elancaster poked IT last week.

Samsung skyrocket arrived in MV today. the device battery is dead and Firefox Beta was just pulled from Play for the l10n issue. i'll leave this on kevin's desk to get to on monday.

confirmed crash on Fx20b1. Logcat attached. Repro: 1) install Fx20.0 beta 1 on Samsung Skyrocket S2 - SGH-I727 2) open browser, goto http://www.canon.com/news/2013/mar04e.html 3) scroll down, and click play on the embedded video in the page 4) browser crashes and crash reporter appears. https://crash-stats.mozilla.com/report/index/bp-b014a12b-e427-411f-a248-a81742130412

one more full logcat, same STR as above, but this time on Firefox 21 b1. Crash report: https://crash-stats.mozilla.com/report/index/bp-1edde3de-4857-4298-b3b2-ee2b72130412

(In reply to Chris Double (:doublec) from comment #4) > (In reply to Alex Keybl [:akeybl] from comment #3) > > Would also be great to get clarification around whether we actually believe > > this is a single issue, or just a bucket. Chris? > > It's not possible to know without being able to reproduce and investigate, > sorry. Chris, we have the device now and the latest logcat and STR from QA are attached in this bug . Do we need anything more that can help speed-up with your investigation here given we have a device handy-now and trying to resolve this in Fx21 time frame.

Looks like it's using a video color format we don't support. We'll probably need to blocklist these devices unless bug 860599 fixes it.

Passing on to Chris to help with blocklist if bug 860599 is not resolved in Fx21 timeframe.

I've updated https://wiki.mozilla.org/Blocklisting/Blocked_Graphics_Drivers#On_Android_2 accordingly.

http://hg.mozilla.org/releases/mozilla-aurora/rev/f0fefaa1d330 http://hg.mozilla.org/releases/mozilla-beta/rev/20a6950ebc7e

It's not fixed because the Equals operator is used to compare model names for the blocklist and also because I757 is missing: Samsung SGH-I717M Samsung SGH-I717 Samsung SGH-I717R Samsung SGH-I727 Samsung SGH-I757M Samsung SGH-T989

(In reply to Scoobidiver from comment #25) > Samsung SGH-I717M > Samsung SGH-I717 > Samsung SGH-I717R > Samsung SGH-I727 > Samsung SGH-I757M > Samsung SGH-T989 So is this the complete list and exact strings I need to block to fix this bug?

Thanks for the keeping a close-eye on these blocklist's . If we do not see any landing in a couple of hours then this should get addressed on m-c/aurora asap and make sure the patch we uplift in final-beta addresses all concerns.

(In reply to Scoobidiver from comment #25) > It's not fixed because the Equals operator is used to compare model names > for the blocklist I'm confused what you mean by this. Can you expand? Looking at: https://crash-stats.mozilla.com/report/index/c86e514b-98ab-4c4c-8686-aa0b02130227 I see the model name is "SGH-T989" which is what is checked in the bug. What is the exact list of model names you'd like blocked if that is not it?

(In reply to Chris Double (:doublec) from comment #28) > (In reply to Scoobidiver from comment #25) > > It's not fixed because the Equals operator is used to compare model names > > for the blocklist > I'm confused what you mean by this. Can you expand? bp-e1e99b1c-24c4-4a8d-9f34-2e4672130501 is a good example. cModel is equal to SAMSUNG-SGH-I717 (Model field) and not to SGH-I717 (Product field). (In reply to Chris Double (:doublec) from comment #26) > (In reply to Scoobidiver from comment #25) > > Samsung SGH-I717M > > Samsung SGH-I717 > > Samsung SGH-I717R > > Samsung SGH-I727 > > Samsung SGH-I757M > > Samsung SGH-T989 > So is this the complete list and exact strings I need to block to fix this > bug? If think you should use something like cModel.Contains (I don't know string operators) for the following models: SGH-I717 SGH-I727 SGH-I757 SGH-T989

(In reply to Scoobidiver from comment #29) > bp-e1e99b1c-24c4-4a8d-9f34-2e4672130501 is a good example. cModel is equal > to SAMSUNG-SGH-I717 (Model field) and not to SGH-I717 (Product field). Ugh, that's annoying, thanks. I'll adjust the patch.

Also, when you do another patch, you probably should correct the comment to say "Samsung" instead of "Samsing" ;-)

Chris can you please help with landing the needed revised patch on m-c ,aurora asap, so QA can verify it and we can uplift before Friday EOD PT in preparation for our final beta? Thanks !

I can look at this when i get back into town next monday. the device is in MV.

taking

I was just told by relmgmt that this patch is landing tomorrow's m-c, but they'd like to take this patch for beta once verified. Kevin, i'll reassign to you since you're in MV. this should hold higher priority over the LG Optimus crash (bug 856445) Steps to verify: 1) download m-c build from may 3rd on skyrocket 2) goto URL in comment 15, and click play. verify it shouldnt play nor crash. 3) set the blocklist off for the device (stagefright.force-enabled = true) 4) repeat step 2, this time confirm video plays and crashes (as expected)

Comment on attachment 744437 [details] [diff] [review] Fix [Approval Request Comment] Bug caused by (feature/regressing bug #): Phones crashing. User impact if declined: Popular devices will crash playing h.264 videos Testing completed (on m-c, etc.): Unable to test due to lack of devices in question Risk to taking this patch (and alternatives if risky): Phones that don't crash might be blocked from playing h.264 video String or IDL/UUID changes made by this patch: None

Comment on attachment 744437 [details] [diff] [review] Fix [Approval Request Comment] Bug caused by (feature/regressing bug #): Phones crashing. User impact if declined: Popular devices will crash playing h.264 videos Testing completed (on m-c, etc.): Unable to test due to lack of devices in question Risk to taking this patch (and alternatives if risky): Phones that don't crash might be blocked from playing h.264 video String or IDL/UUID changes made by this patch: None

Requesting some exploratory QA testing on popular Samsung devices to make sure we are just blocklisting the needed devices given the risk in comment# 39 .

FWIW, I have one of the Note affected with ICS: SGH-717M (it is my personal Phablet) If you ever need.

I've added SGH-I757 to https://wiki.mozilla.org/Blocklisting/Blocked_Graphics_Drivers#On_Android_2

Verified on a inbound build. This did not make the cutoff for today's nightly. Using the "Video for everybody" the SII falls back to webm.

(In reply to Kevin Brosnan [:kbrosnan] from comment #46) > Verified on a inbound build. This did not make the cutoff for today's > nightly. Using the "Video for everybody" the SII falls back to webm. Thanks Kevin ! Adding back verifyme to do some testing on our final beta build as a part of final beta sign-off.

Verified Firefox 21 and 22.

It's #24 crasher in 21.0 and #53 in 22.0b1.

What's the status of this?

I still get crashes when playing .mp4 videos with Firefox 30.0 on a T-Mobile Samsung Galaxy S II. (SGH-T989, with Qualcomm Adreno 220) I'm using my carrier's build of Android 4.0.4. WebM video, Ogg audio, and MP3 audio all play fine. Here's a crash report matching one of the signatures in this bug. https://crash-stats.mozilla.com/report/index/a1b1aaf3-9891-48ad-8158-cf00f2140627 I'd be happy to help out with debugging or testing on my phone.

I did some more debugging, results and a preliminary patch are in follow-up bug 1032059.

filter on [mass-p5]