crash in mozilla::MediaCacheStream::SetReadMode @ on Sony Ericsson LT26 running JB 4.1

RESOLVED FIXED in Firefox 22



5 years ago
4 years ago


(Reporter: Scoobidiver (away), Assigned: bjacob)


({crash, qawanted, topcrash})

crash, qawanted, topcrash

Firefox Tracking Flags

(firefox21 wontfix, firefox22+ fixed, firefox23+ fixed, firefox24 fixed)


(Whiteboard: [native-crash], crash signature)


(2 attachments)



5 years ago
It's #44 crasher in 21.0 and #26 in 22.0b3. It first showed up on April 28.

Here is the breakdown per device:
Sony Ericsson LT26i 	130
Sony Ericsson LT26w 	19
Sony Ericsson LT26ii 	11
Sony Ericsson LT28h 	2

Sony devices are blocklisted for Stagefright on JB (bug 845734) but Sony Ericsson ones are not (.Equals instead of .Find). See bp-dc2459be-ec55-4682-b70c-befb72130603.

Signature 	@0x0 | More Reports Search
UUID	3df3b5f1-b326-4139-9f9e-d1edc2130604
Date Processed	2013-06-04 02:53:14
Uptime	224
Last Crash	3.9 minutes before submission
Install Age	4.0 days since version was first installed.
Install Time	2013-05-31 02:21:08
Product	FennecAndroid
Version	22.0
Build ID	20130528175857
Release Channel	beta
OS	Android
OS Version	0.0.0 Linux 3.4.0+1.0.21100-313065-g1ccebb5-00165-g78362b4 #1 SMP PREEMPT Wed Apr 24 10:01:32 2013 armv7l SEMC/LT26w_1266-2032/LT26w:4.1.2/6.2.B.0.200/N7__zg:user/release-keys
Build Architecture	arm
Build Architecture Info	ARMv0
Crash Reason	SIGSEGV
Crash Address	0x0
App Notes 	
AdapterDescription: 'Qualcomm -- Adreno (TM) 220 -- OpenGL ES 2.0 V@6.0 AU@ (CL@) -- Model: LT26w, Product: LT26w_1266-2032, Manufacturer: Sony Ericsson, Hardware: semc'
EGL? EGL+ GL Context? GL Context+ GL Layers? GL Layers+ 
Sony Ericsson LT26w
Processor Notes 	sp-processor05_phx1_mozilla_com_19323:2012; exploitability tool: ERROR: unable to analyze dump
EMCheckCompatibility	True
Adapter Vendor ID	Qualcomm
Adapter Device ID	Adreno (TM) 220
Device	Sony Ericsson LT26w
Android API Version	16 (REL)
Android CPU ABI	armeabi-v7a

Frame 	Module 	Signature 	Source
0 		@0x0 	
2 	linker 	linker@0x4e1d 	
4 	linker 	linker@0x14bc6 	
5 	linker 	linker@0x1489e 	
6 	linker 	linker@0x50e3 	
9 (deleted) @0x23bf 	
11 (deleted) @0x23bf 	
17 	mozilla::MediaCacheStream::SetReadMode 	content/media/MediaCache.cpp:2018
18 (deleted) @0x1dad 	

More reports at:|

Comment 1

5 years ago
This is rising fast in 21 crash stats on Android, #18 in yesterday's data.


5 years ago
status-firefox24: --- → affected
Whiteboard: [native-crash]
Version: 21 Branch → Trunk

Comment 2

5 years ago
It's #12 crasher in 21.0 and #14 in 22.0b4.

The patch consist to replace:
          cManufacturer.Equals("Sony", nsCaseInsensitiveCStringComparator());
          cManufacturer.Find("Sony", true) != -1;
tracking-firefox22: --- → ?

Comment 3

5 years ago
(In reply to Robert Kaiser ( [away until early June] from comment #1)
> This is rising fast in 21 crash stats on Android, #18 in yesterday's data.

This is due to
status-firefox21: affected → wontfix
tracking-firefox22: ? → +
tracking-firefox23: --- → +

Comment 4

5 years ago
bjacob - does Scoobidiver's suggestion in Comment 2 sound like the right path forward?
Assignee: nobody → bjacob

Comment 5

5 years ago
Yup, it's correct, even correctly has the != -1 that I mistakenly forgot recently causing a lot of trouble :)


Comment 6

5 years ago
...except for one thing: we want to keep using a case-insensitive comparison. I just grepped through some crash reports, and a very small minority have 'sony' all lowercase, even in the Manufacturer field.

Comment 7

5 years ago
Created attachment 761067 [details] [diff] [review]
match Sony as a substring, case-insensitive
Attachment #761067 - Flags: review?(joe)
Attachment #761067 - Flags: review?(joe) → review+

Comment 8

5 years ago

Scoobidiver: modulo the case-insensitive part, this is basically your patch. Next time don't hesitate to submit a patch and/or ask for help with that (say, on IRC #developers or #gfx).
Target Milestone: --- → mozilla24

Comment 9

5 years ago
Comment on attachment 761067 [details] [diff] [review]
match Sony as a substring, case-insensitive

[Approval Request Comment]
Bug caused by (feature/regressing bug #): n/a, driver bug we were not yet blacklisting
User impact if declined: topcrasher on android
Testing completed (on m-c, etc.): m-i
Risk to taking this patch (and alternatives if risky): no risk thanks to having carefully read and re-read this one-line patch
String or IDL/UUID changes made by this patch: none
Attachment #761067 - Flags: approval-mozilla-beta?
Attachment #761067 - Flags: approval-mozilla-aurora?

Comment 10

5 years ago
(In reply to Benoit Jacob [:bjacob] from comment #8)
> Next time don't hesitate to submit a patch and/or ask for help with that
It's not easy to submit a patch on Windows according to
The only Windows-specific issue is line endings; it is just a matter of telling your text editor to generate Unix-style line endings. There is no other windows-specific issue that I know (and I have generated patches under Windows). If a wiki page suggests otherwise, it may need to be clarified.


5 years ago
Attachment #761067 - Flags: approval-mozilla-beta?
Attachment #761067 - Flags: approval-mozilla-beta+
Attachment #761067 - Flags: approval-mozilla-aurora?
Attachment #761067 - Flags: approval-mozilla-aurora+
We'll want to do some spot checking of this change to make sure we didn't disable more than we intended, Aaron.
Keywords: qawanted, verifyme
QA Contact: aaron.train
Created attachment 761145 [details]
patch that actually compiles (nsCString is crazy)

it turns out that while nsCString::Find on a nsCString takes a Comparator, nsCString::Find on a const char * wants a |bool ignoreCase| !!
As a result of this stupid compiler error, the tree has been closed, and I am not allowed to re-land on CLOSED TREE. This is the last time I rush a last minute blocklist fix. Future ones will go on tryserver no matter how urgent they may be.
Which means don't even bother asking me for a same-day fix.
status-firefox22: affected → fixed
status-firefox23: --- → fixed
status-firefox24: affected → fixed
Last Resolved: 5 years ago
Resolution: --- → FIXED


5 years ago
Keywords: topcrash
This was filed against Android 4.1, patched against Android 4.2 ( and documented against Android 4.1 - is this a mistake, should the check be in the if/else block above?
nevermind I see how CompareVersions()'s works here in this case

Comment 23

5 years ago
Do those approvals mean I can just land?

Comment 24

5 years ago
Oops, wrong bug.
mass remove verifyme requests greater than 4 months old
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.