853522 - crash in mozilla::MediaPluginHost::DestroyDecoder @ libstagefright.so@0xd... on Samsung Galaxy Tab 2 with espresso & espresso10 hw running JB

Status: VERIFIED FIXED

(Core :: Audio/Video, defect)

Description

[Scoobidiver (away)]

It's currently #57 top crasher in 19.0.2.
The affected devices are:
Samsung GT-P3113 (Galaxy Tab 2 7")	46
Samsung GT-P3110 (Galaxy Tab 2 7")	37

Signature 	libstagefright.so@0xdcb21 More Reports Search
UUID	a6173e6c-1bb7-4928-aeb1-c75b32130321
Date Processed	2013-03-21 04:49:06
Uptime	1207
Install Age	1.8 weeks since version was first installed.
Install Time	2013-03-08 17:52:50
Product	FennecAndroid
Version	19.0.2
Build ID	20130307022932
Release Channel	release
OS	Android
OS Version	0.0.0 Linux 3.0.31-523998 #1 SMP PREEMPT Fri Nov 30 11:30:39 KST 2012 armv7l samsung/espressowifiue/espressowifi:4.1.1/JRO03C/P3113UECLK7:user/release-keys
Build Architecture	arm
Build Architecture Info	
Crash Reason	SIGSEGV
Crash Address	0xdeadbaad
App Notes 	
AdapterDescription: 'Imagination Technologies -- PowerVR SGX 540 -- OpenGL ES 2.0 build 1.9@2120756 -- Model: GT-P3113, Product: espressowifiue, Manufacturer: samsung, Hardware: espresso'
EGL? EGL+ GL Context? GL Context+ GL Layers? GL Layers+ Stagefright? Stagefright+ 
samsung GT-P3113
samsung/espressowifiue/espressowifi:4.1.1/JRO03C/P3113UECLK7:user/release-keys
Processor Notes 	sp-processor03.phx1.mozilla.com_10304:2008; exploitablity tool: ERROR: unable to analyze dump
EMCheckCompatibility	True
Adapter Vendor ID	Imagination Technologies
Adapter Device ID	PowerVR SGX 540
Device	samsung GT-P3113
Android API Version	16 (REL)
Android CPU ABI	armeabi-v7a

Frame 	Module 	Signature 	Source
0 	libc.so 	libc.so@0x1821e 	
1 	libstagefright.so 	libstagefright.so@0xdcb21 	
2 	libstagefright.so 	libstagefright.so@0xdcb21 	
3 	libc.so 	libc.so@0xdc16 	
4 	libcutils.so 	libcutils.so@0x3d43 	
5 	libcutils.so 	libcutils.so@0x410b 	
6 	org.mozilla.firefox-2.apk 	org.mozilla.firefox-2.apk@0xb61369 	
7 	dalvik-heap (deleted) 	dalvik-heap @0xe246466 	
8 	dalvik-heap (deleted) 	dalvik-heap @0x43d331e 	
9 	dalvik-heap (deleted) 	dalvik-heap @0x4543b41 	
10 	ashmem (deleted) 	ashmem @0x1684f 	
11 	libxul.so 	base::Histogram::Accumulate 	ipc/chromium/src/base/histogram.cc:562
12 	libxul.so 	base::Histogram::Add 	ipc/chromium/src/base/histogram.cc:130
13 		@0x5f1ff5b6 	
14 	libxul.so 	js::gcstats::Statistics::beginSlice 	js/src/gc/Statistics.cpp:573
15 		@0x7ccb23cd 	
16 	libstagefright.so 	libstagefright.so@0x814fd 	
17 	libstagefright.so 	libstagefright.so@0xca0f0 	
18 	libomxplugin.so 	OmxPlugin::OmxDecoder::~OmxDecoder 	OmxPlugin.cpp:214
19 	libomxplugin.so 	OmxPlugin::DestroyDecoder 	OmxPlugin.cpp:845
20 	libxul.so 	mozilla::MediaPluginHost::DestroyDecoder 	content/media/plugins/MediaPluginHost.cpp:189
21 	libxul.so 	mozilla::MediaPluginReader::ResetDecode 	content/media/plugins/MediaPluginReader.cpp:106
22 	libxul.so 	mozilla::MediaPluginReader::~MediaPluginReader 	content/media/plugins/MediaPluginReader.cpp:31
23 	libxul.so 	mozilla::MediaPluginReader::~MediaPluginReader 	content/media/plugins/MediaPluginReader.cpp:32
24 	libxul.so 	mozilla::MediaDecoderStateMachine::~MediaDecoderStateMachine 	nsAutoPtr.h:40
25 	libxul.so 	mozilla::MediaDecoderStateMachine::~MediaDecoderStateMachine 	content/media/MediaDecoderStateMachine.cpp:457
26 	libxul.so 	nsRunnable::Release 	obj-firefox/xpcom/build/nsThreadUtils.cpp:31
27 	libxul.so 	nsCOMPtr_base::assign_assuming_AddRef 	nsCOMPtr.h:442
28 	libxul.so 	nsCOMPtr_base::assign_with_AddRef 	obj-firefox/xpcom/build/nsCOMPtr.cpp:49
29 	libxul.so 	mozilla::nsDecoderDisposeEvent::Run 	nsCOMPtr.h:624
30 	libxul.so 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:627
31 	libxul.so 	NS_ProcessNextEvent_P 	obj-firefox/xpcom/build/nsThreadUtils.cpp:238
32 	libxul.so 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:82
33 	libxul.so 	MessageLoop::RunInternal 	ipc/chromium/src/base/message_loop.cc:215
34 	libxul.so 	MessageLoop::Run 	ipc/chromium/src/base/message_loop.cc:208
35 	libxul.so 	nsBaseAppShell::Run 	widget/xpwidgets/nsBaseAppShell.cpp:163
36 	libxul.so 	nsAppStartup::Run 	toolkit/components/startup/nsAppStartup.cpp:290
37 	libxul.so 	XREMain::XRE_mainRun 	toolkit/xre/nsAppRunner.cpp:3823
38 	libxul.so 	XREMain::XRE_main 	toolkit/xre/nsAppRunner.cpp:3890
39 	libxul.so 	XRE_main 	toolkit/xre/nsAppRunner.cpp:4084

More reports at:
https://crash-stats.mozilla.com/report/list?signature=libstagefright.so%400xdcb21

Comment 1

[cajbir (:cajbir)]

I've requested a device to use for testing.

Comment 2

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Is this the model available from service now?

Comment 3

[Scoobidiver (away)]

It's more generic and affects all Galaxy Tab 2 models.
With combined signatures, it's #9 top crasher in 20.0.1 and #12 in 21.0b3.

Here are affected devices in 20.0 on April 24 (latest data available):
* libstagefright.so@0xdcb21 	93
Samsung GT-P3113 	49
Samsung GT-P3110 	44
* libstagefright.so@0xdd896 	56
Samsung GT-P5113 	56
* libstagefright.so@0xdec33 	47
Samsung GT-P5100 	25
Samsung GT-P3100 	22
* libstagefright.so@0xdd1a6 	43
Samsung GT-P5110 	43
* libstagefright.so@0xddce0 	27
Samsung GT-P3110 	27
* libstagefright.so@0xde3e8 	10
Samsung GT-P3100 	10
* libstagefright.so@0xdd209 	9
Samsung GT-P3100 	7
Samsung GT-P3100B 	2
* libstagefright.so@0xdec9c 	8
Samsung GT-P5100 	4
Samsung GT-P3100 	4
* libstagefright.so@0xdec7b 	7
Samsung GT-P3100 	7
* libstagefright.so@0xdece4 	5
Samsung GT-P3100 	5
* libstagefright.so@0xdfa08 	4
Samsung GT-P5110 	4

Comment 4

[bhavana bajaj [:bajaj]]

(In reply to Chris Double (:doublec) from comment #1)
> I've requested a device to use for testing.

Chris, what are our next steps here ? Not sure if this was investigated based on the device you may have received or if this needs QA.

Comment 5

[cajbir (:cajbir)]

I'm expecting bug 860599 to fix it. We should blocklist if you consier it urgent enough.

Comment 6

[bhavana bajaj [:bajaj]]

(In reply to Chris Double (:doublec) from comment #5)
> I'm expecting bug 860599 to fix it. We should blocklist if you consier it
> urgent enough.

If this is similar to the other stagefright issue's that we have been dealing with recently due to the whitelist in https://bugzilla.mozilla.org/show_bug.cgi?id=823253.
Then we will be introducing a new crash for user's & to avoid that we should be doing a similar blocklist that we have been doing.

but the fact that Firefox version < 21 are also affected here, I am confused of the cause of the crasher.Can you please help clarify that?

Comment 7

[cajbir (:cajbir)]

(In reply to bhavana bajaj [:bajaj] from comment #6)
> 
> but the fact that Firefox version < 21 are also affected here, I am confused
> of the cause of the crasher.Can you please help clarify that?

I don't know the cause sorry and won't be able to look into it until bug 860599 is done.

Comment 8

[Scoobidiver (away)]

(In reply to bhavana bajaj [:bajaj] from comment #6)
> but the fact that Firefox version < 21 are also affected here, I am confused
> of the cause of the crasher.Can you please help clarify that?
JB was allowed in Firefox 17 with bug 782508.
The high volume described in comment 3 is likely caused by data not aggregated and maybe an upgrade to JB post-Firefox 17. Indeed, every signatures are low independently and were off my radar. Debug symbols for Stagefright would have helped detecting it sooner.

This bug is like bug 845734 which was appeared with the upgrade of Sony devices to JB.

Comment 9

[bhavana bajaj [:bajaj]]

Adding qawanted to get some testing on "Samsung GT-P3113 (Galaxy Tab 2 7")" or	
Samsung GT-P3110 (Galaxy Tab 2 7") to see how soon is this crash happening ?OR give some more information on the user experience if they are able to reproduce the crash.

Comment 10

[bhavana bajaj [:bajaj]]

needsinfo on :Kairo for urls that can help QA.

Comment 11

[Aaron Train [:aaronmt]]

Using my Samsung Galaxy Tab 2 7.0" (GT-P3113 WIFI, ARMv7 Espresso) running Android 4.1 (firmware update to 4.1.1 ) I haven't been able to reproduce any crash on mozilla-central nor mozilla-beta. A good 45 minutes spent running non-stop media from: http://people.mozilla.org/~cpeterson/videos/, http://people.mozilla.com/~atrain/mobile/tests/media.html, http://cd.pn/b/

Comment 12

[Alex Keybl [:akeybl]]

One SFW URL I was able to pull out http://www.tudou.com/albumplay/wbaZucJq-pI/3QQ7IAmB3uA.html (in case this is video file specific)

Comment 13

[bhavana bajaj [:bajaj]]

Adding needsinfo on Aaron to give this url a shot, else see if he is able to reproduce the crash.

Also can you please explain what the behavior we should be seeing after blocklisting stagefright.I am assuming it would avoid the crash and the be media should get playback. Are we doing this verification for the blocklists that have recently gone in on Fx21 beta(cc :kbrosnan)?

Comment 14

[bhavana bajaj [:bajaj]]

needsinfo on Chris to help understand if blocklisting is the best approach here given comment #8 and considering the recent volume of crashes on release https://crash-stats.mozilla.com/report/list?signature=libstagefright.so%400xdcb21 .We have taken a similar course of action for Sony devices running Jellybean in Bug 845734 .

Comment 15

[Kevin Brosnan [Ex-Mozilla]]

The Galaxy tab 2 that MV QA has is currently running Android 3.1 (Honeycomb) it is one of our last remaining 3.1 devices. It sounds like Aaron has an updated device.

Comment 16

[cajbir (:cajbir)]

(In reply to bhavana bajaj [:bajaj] from comment #14)
> needsinfo on Chris to help understand if blocklisting is the best approach
> here given comment #8 and considering the recent volume of crashes on
> release
> https://crash-stats.mozilla.com/report/list?signature=libstagefright.
> so%400xdcb21 .We have taken a similar course of action for Sony devices
> running Jellybean in Bug 845734 .

Sure, blocklisting is fine. Someone will need to give me a list of device strings to block that satisfies this as being 'resolved'.

Comment 17

[bhavana bajaj [:bajaj]]

(In reply to Chris Double (:doublec) from comment #16)
> (In reply to bhavana bajaj [:bajaj] from comment #14)
> > needsinfo on Chris to help understand if blocklisting is the best approach
> > here given comment #8 and considering the recent volume of crashes on
> > release
> > https://crash-stats.mozilla.com/report/list?signature=libstagefright.
> > so%400xdcb21 .We have taken a similar course of action for Sony devices
> > running Jellybean in Bug 845734 .
> 
> Sure, blocklisting is fine. Someone will need to give me a list of device
> strings to block that satisfies this as being 'resolved'.

Thanks Chris! Adding needsinfo on Scoobidiver and :Kairo to see if they can help here.

Comment 18

[Aaron Train [:aaronmt]]

(In reply to Kevin Brosnan [:kbrosnan] from comment #15)
> The Galaxy tab 2 that MV QA has is currently running Android 3.1 (Honeycomb)
> it is one of our last remaining 3.1 devices. It sounds like Aaron has an
> updated device.

Mine shipped with Android 4.0 (ICS) http://www.samsung.com/ca/consumer/mobile/mobile-phones/tablets/GT-P3113TSAXAC-spec

(In reply to Alex Keybl [:akeybl] from comment #12)
> One SFW URL I was able to pull out
> http://www.tudou.com/albumplay/wbaZucJq-pI/3QQ7IAmB3uA.html (in case this is
> video file specific)

No crash on this URL.

Comment 19

[bhavana bajaj [:bajaj]]

(In reply to Aaron Train [:aaronmt] from comment #18)
> (In reply to Kevin Brosnan [:kbrosnan] from comment #15)
> > The Galaxy tab 2 that MV QA has is currently running Android 3.1 (Honeycomb)
> > it is one of our last remaining 3.1 devices. It sounds like Aaron has an
> > updated device.
> 
> Mine shipped with Android 4.0 (ICS)
> http://www.samsung.com/ca/consumer/mobile/mobile-phones/tablets/GT-
> P3113TSAXAC-spec
> 
> (In reply to Alex Keybl [:akeybl] from comment #12)
> > One SFW URL I was able to pull out
> > http://www.tudou.com/albumplay/wbaZucJq-pI/3QQ7IAmB3uA.html (in case this is
> > video file specific)
> 
> No crash on this URL.

hey Aaron,Just making sure this was tried on JB and not ics ?

Comment 20

[Aaron Train [:aaronmt]]

(In reply to bhavana bajaj [:bajaj] from comment #19)
>
> hey Aaron,Just making sure this was tried on JB and not ics ?

It's 4.1.1 as mentioned in comment #11.

Comment 21

[Benoit Jacob [:bjacob] (mostly away)]

(In reply to Chris Double (:doublec) from comment #16)
> (In reply to bhavana bajaj [:bajaj] from comment #14)
> > needsinfo on Chris to help understand if blocklisting is the best approach
> > here given comment #8 and considering the recent volume of crashes on
> > release
> > https://crash-stats.mozilla.com/report/list?signature=libstagefright.
> > so%400xdcb21 .We have taken a similar course of action for Sony devices
> > running Jellybean in Bug 845734 .
> 
> Sure, blocklisting is fine. Someone will need to give me a list of device
> strings to block that satisfies this as being 'resolved'.

See https://bugzilla.mozilla.org/show_bug.cgi?id=824118#c12 that I wrote on this subject for another crash. You first need to download pub-crashdata CSV files from https://crash-analysis.mozilla.com/crash_analysis .

Comment 22

[cajbir (:cajbir)]

(In reply to Benoit Jacob [:bjacob] from comment #21)
> 
> See https://bugzilla.mozilla.org/show_bug.cgi?id=824118#c12 that I wrote on
> this subject for another crash. You first need to download pub-crashdata CSV
> files from https://crash-analysis.mozilla.com/crash_analysis .

Thanks but I'll wait for Scoobidiver to get back. Everytime I research the list myself Scoobidiver ends up reopening the bug with other devices. I prefer to avoid that and have them list the devices they want blocked when they open the bug.

Comment 23

[cajbir (:cajbir)]

I'll prepare a patch with the affected devices in comment 3 for now.

Comment 24

[cajbir (:cajbir)]

Attachment: Block devices identified in comment 3

Comment 25

[Scoobidiver (away)]

(In reply to Chris Double (:doublec) from comment #23)
> I'll prepare a patch with the affected devices in comment 3 for now.
You shouldn't block a device twice because it shows up under several crash signatures. Sorting them out is also easier to check:
GT-P3100
GT-P3110
GT-P3113
GT-P5100
GT-P5110
GT-P5113

Comment 26

[cajbir (:cajbir)]

(In reply to Scoobidiver from comment #25)
> Sorting them out is also easier to check

Great idea, I'd appreciate you providing sorted lists of actual devices to be blocked when raising bugs, thanks!

Comment 27

[cajbir (:cajbir)]

Attachment: Block devices identified in comment 25

Comment 28

[Scoobidiver (away)]

(In reply to Chris Double (:doublec) from comment #26)
> Great idea, I'd appreciate you providing sorted lists of actual devices to
> be blocked when raising bugs, thanks!
Comment 3 is an extract of rkaiser's correlation files to know the breakdown per device and was not intended to be the patch. Figuring out which devices are better to block was another step.

Comment 29

[Tracy Walker [:tracy]]

 	http://www.justream.net/2013/04/de-lautre-cote-du-periph.html
1 	http://www.animeflavor.com/naruto-shippuden-episode-311-prologue-road-ninja
1 	http://www1.watchop.com/watch/one-piece-episode-589-english-subbed/
1 	https://class.coursera.org/interactivepython-002/lecture/17
1 	http://news.google.fr/news/section?pz=1&cf=all&ned=fr&topic=t&siidp=444065c490bc
1 	http://www.free-tv-video-online.me/player/putlocker.php?id=3ADF44E6803950F1
1 	http://www1.watchop.com/watch/one-piece-episode-566-english-subbed/
1 	http://www1.watchop.com/watch/one-piece-episode-561-english-subbed/
1 	http://v.youku.com/v_show/id_XNDU1OTIzNTg4.html?x
1 	http://www.6pm.com/mens-shoes%7Es?s=isNew/desc/goLiveDate/desc/recentSalesStyle/
1 	http://www.panet.co.il/Ext/series.php?name=folder&id=1047
1 	about:blank
1 	http://m.linternaute.com/linternaute/actualite/societe-france/1er-mai-les-origin
1 	http://www.novamov.com/mobile/?id=kpnib9gcnid86

Comment 30

[Benoit Jacob [:bjacob] (mostly away)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/7ded7165ab87

Comment 31

[Benoit Jacob [:bjacob] (mostly away)]

Comment on attachment 745084 [details] [diff] [review]
Block devices identified in comment 25

[Approval Request Comment]
Bug caused by (feature/regressing bug #): h264 video
User impact if declined: crashes
Testing completed (on m-c, etc.): m-i
Risk to taking this patch (and alternatives if risky): very low, simple blocklist update
String or IDL/UUID changes made by this patch: none

Comment 32

[Benoit Jacob [:bjacob] (mostly away)]

https://hg.mozilla.org/releases/mozilla-beta/rev/e988bcfd097c
https://hg.mozilla.org/releases/mozilla-aurora/rev/7539d742bee9

Comment 33

[bhavana bajaj [:bajaj]]

Although, QA is unable to reproduce the crash we should make sure that the blocklist testing should be done here by running h264 video's and making sure we are observing the expected behavior.In most video's I am guessing it should fallback to other s/w decoding ( use mp3 format or something else here for playback ) .

Please make sure to test this on nightly/aurora once this lands and definitely on beta builds once available.Thank you !

Comment 34

[Scoobidiver (away)]

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

Comment 35

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/7ded7165ab87

Comment 36

[cajbir (:cajbir)]

Unfortunately this blocked almost all JB devices. See bug 868826.

Comment 37

[cajbir (:cajbir)]

Attachment: Backout on beta

Backout due to regression identified in bug 868826.

Comment 38

[Benoit Jacob [:bjacob] (mostly away)]

Comment on attachment 747070 [details] [diff] [review]
Backout on beta

Review of attachment 747070 [details] [diff] [review]:
-----------------------------------------------------------------

r=me. Sorry again about the failed review job on that patch.

Comment 39

[cajbir (:cajbir)]

Comment on attachment 747070 [details] [diff] [review]
Backout on beta

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Fix was unfortunately broken
User impact if declined: Most 4.1.x android devices won't play h.264/mp3
Testing completed (on m-c, etc.): None.
Risk to taking this patch (and alternatives if risky): Devices originally intended to block will crash instead.
String or IDL/UUID changes made by this patch: None.

Comment 40

[bhavana bajaj [:bajaj]]

Comment on attachment 747070 [details] [diff] [review]
Backout on beta

Approving the backout on beta here and we will be spinning a Fx21.0b8 for mobile to help avoid Bug 868826 . We are aware this crash may not be resolved in Fx21.0 but the is best fwd approach based on the risk of unexpectedly blocklisting devices.Please land asap.

Chris, please let us know if the backout here is needed on aurora as well or the fwd fix in Bug 868826 should take care of this in aurora

Comment 41

[cajbir (:cajbir)]

https://hg.mozilla.org/releases/mozilla-beta/rev/3d5bcc17aa40

Comment 42

[bhavana bajaj [:bajaj]]

Adding qawanted,verifyme to get some testing here to make sure stagefright is not disabled on JB devices.

Comment 43

[cajbir (:cajbir)]

(In reply to bhavana bajaj [:bajaj] from comment #40)
> Chris, please let us know if the backout here is needed on aurora as well or
> the fwd fix in Bug 868826 should take care of this in aurora

The fix in bug 868826 takes care of aurora.

Comment 44

[cajbir (:cajbir)]

(In reply to bhavana bajaj [:bajaj] from comment #42)
> Adding qawanted,verifyme to get some testing here to make sure stagefright
> is not disabled on JB devices.

I'll test the JB devices I have at the office when I get in this morning.

Comment 45

[Scoobidiver (away)]

(In reply to Chris Double (:doublec) from comment #41)
> https://hg.mozilla.org/releases/mozilla-beta/rev/3d5bcc17aa40
It will add again a top crasher.

Comment 46

[Robert Kaiser]

(In reply to Scoobidiver from comment #45)
> (In reply to Chris Double (:doublec) from comment #41)
> > https://hg.mozilla.org/releases/mozilla-beta/rev/3d5bcc17aa40
> It will add again a top crasher.

Yes, that's calculated risk at this time.

Comment 47

[bhavana bajaj [:bajaj]]

(In reply to Scoobidiver from comment #45)
> (In reply to Chris Double (:doublec) from comment #41)
> > https://hg.mozilla.org/releases/mozilla-beta/rev/3d5bcc17aa40
> It will add again a top crasher.

Yep, I am ok with eating up that top-crasher for Fx21.0 but i do really want to make sure that the backout patch here which is recently approved will get us in the same state as we were in for Fx21.0b6.

needsinfo on :doublec,:bjacob here to confirm ,as the patch " Block devices identified in comment 25 " vs " Backout on beta " do not seem identical.Do we need to add back the following code in the backout ?

-          cModel.Equals("SAMSUNG-SPH-L710", nsCaseInsensitiveCStringComparator()) ||
-          cModel.Equals("SAMSUNG-SGH-T999", nsCaseInsensitiveCStringComparator()) ||
-          cModel.Equals("SAMSUNG-SCH-I535", nsCaseInsensitiveCStringComparator()) ||
-          cModel.Equals("SAMSUNG-GT-I8190", nsCaseInsensitiveCStringComparator()) ||
-          cModel.Equals("SAMSUNG-SGH-I747M", nsCaseInsensitiveCStringComparator()) ||
-          cModel.Equals("SAMSUNG-SGH-I747", nsCaseInsensitiveCStringComparator()) 

Sorry about being extra paranoid here, but I had just had this doubt in mind.

Comment 48

[Benoit Jacob [:bjacob] (mostly away)]

Hm, this seems to be because the original patch is against Mozilla-central while the backout patch is against mozilla-beta, which has an older version of the blocklisting code with fewer rules. So, I wouldn't worry.

Comment 49

[bhavana bajaj [:bajaj]]

(In reply to Benoit Jacob [:bjacob] from comment #48)
> Hm, this seems to be because the original patch is against Mozilla-central
> while the backout patch is against mozilla-beta, which has an older version
> of the blocklisting code with fewer rules. So, I wouldn't worry.

Ok, thanks .I just realized too, that the cset in beta was rebased and the patch posted here was for m-c.

Comment 50

[bhavana bajaj [:bajaj]]

Chris, since we have already done the beta->release merge and we have the final RC builds out there we would have to exclusively  land this patch on mozilla-release as well .Once landed the changeset will be used for doing the RC build#2 here.

basically,please request approval nomination for mozilla-release and once approved land it on that branch?

Comment 51

[cajbir (:cajbir)]

Comment on attachment 747070 [details] [diff] [review]
Backout on beta

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Fix was unfortunately broken
User impact if declined: Most 4.1.x android devices won't play h.264/mp3
Testing completed (on m-c, etc.): None.
Risk to taking this patch (and alternatives if risky): Devices originally intended to block will crash instead.
String or IDL/UUID changes made by this patch: None.

Comment 52

[cajbir (:cajbir)]

https://hg.mozilla.org/releases/mozilla-release/rev/9b381be28beb

Comment 53

[Aaron Train [:aaronmt]]

Verified Fixed on mozilla-release/mozilla-beta

Devices tested

* Alcatel One Touch 8008X (Android 4.1)
* Samsung Galaxy Nexus (Android 4.2)
* Samsung Nexus S (Android 4.1)
* Asus Transformer Prime TF201 (Android 4.1)
* LG Nexus 4 (Android 4.2)
* Asus Nexus 7 (Android 4.2)
* Samsung Galaxy Note (Android 4.1
* Samsung Galaxy Note 2 (Android 4.2)
* SGH-I747 (AT&T Samsung Galaxy SIII)
* SPH-L710 (Sprint Samsung Galaxy SIII CDMA)
* Samsung Galaxy Tab 2 7.0 (GT-P3113, Android 4.1)

Comment 54

[Scoobidiver (away)]

(In reply to Aaron Train [:aaronmt] from comment #53)
> Verified Fixed on mozilla-release/mozilla-beta
You meant verified not blocklisted.

Comment 55

[Aaron Train [:aaronmt]]

(In reply to Scoobidiver from comment #54)
> (In reply to Aaron Train [:aaronmt] from comment #53)
> > Verified Fixed on mozilla-release/mozilla-beta
> You meant verified not blocklisted.

Correct.