Closed Bug 970081 Opened 6 years ago Closed 6 years ago

crash in android.content.res.Resources$NotFoundException: Resource is not a Drawable (color or path): TypedValue{t=0x1/d=0x7f0c0061 a=3 r=0x7f0c0061} at android.content.res.Resources.loadDrawable(Resources.java)

Categories

(Firefox for Android :: General, defect, critical)

29 Branch
All
Android
defect
Not set
critical

Tracking

()

VERIFIED FIXED
Firefox 30
Tracking Status
firefox27 --- unaffected
firefox28 + verified
firefox29 --- verified
firefox30 --- verified
b2g-v1.3 --- fixed
fennec 28+ ---

People

(Reporter: kbrosnan, Assigned: bnicholson)

References

Details

(Keywords: crash, topcrash-android-armv7, Whiteboard: [native-crash][honeycomb][Samsung Galaxy Tab Plus])

Crash Data

Attachments

(2 files)

This bug was filed from the Socorro interface and is 
report bp-29240dbf-7ee6-4406-9e2c-190c92140208.
=============================================================

Crash on Android 3.x tablets running Mali 400 GPU. Calling something that does not exist on Android 3.x?

android.content.res.Resources$NotFoundException: Resource is not a Drawable (color or path): TypedValue{t=0x1/d=0x7f0c0061 a=3 r=0x7f0c0061}
	at android.content.res.Resources.loadDrawable(Resources.java:1890)
	at android.content.res.TypedArray.getDrawable(TypedArray.java:601)
	at android.view.View.<init>(View.java:2471)
	at android.view.ViewGroup.<init>(ViewGroup.java:365)
	at android.widget.LinearLayout.<init>(LinearLayout.java:156)
	at android.widget.LinearLayout.<init>(LinearLayout.java:152)
	at java.lang.reflect.Constructor.constructNative(Native Method)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:416)
	at android.view.LayoutInflater.createView(LayoutInflater.java:576)
	at com.android.internal.policy.impl.PhoneLayoutInflater.onCreateView(PhoneLayoutInflater.java:56)
	at android.view.LayoutInflater.onCreateView(LayoutInflater.java:644)
	at android.view.LayoutInflater.createViewFromTag(LayoutInflater.java:669)
	at android.view.LayoutInflater.inflate(LayoutInflater.java:457)
	at android.view.LayoutInflater.inflate(LayoutInflater.java:391)
	at android.view.LayoutInflater.inflate(LayoutInflater.java:347)
	at android.widget.Toast.makeText(Toast.java:247)
	at org.mozilla.gecko.GeckoApp$9.run(GeckoApp.java:836)
	at android.os.Handler.handleCallback(Handler.java:587)
	at android.os.Handler.dispatchMessage(Handler.java:92)
	at android.os.Looper.loop(Looper.java:132)
	at android.app.ActivityThread.main(ActivityThread.java:4123)
	at java.lang.reflect.Method.invokeNative(Native Method)
	at java.lang.reflect.Method.invoke(Method.java:491)
	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:844)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:602)
	at dalvik.system.NativeStart.main(Native Method)
Duplicate of this bug: 970080
Seems to affect largely only the original Samsung Galaxy Tab, the GT-P6200 (Galaxy Tab) as the most reported.

More reports: https://crash-stats.mozilla.com/report/list?product=FennecAndroid&signature=android.content.res.Resources%24NotFoundException%3A+Resource+is+not+a+Drawable+%28color+or+path%29%3A+TypedValue%7Bt%3D0x1%2Fd%3D0x7f0c0061+a%3D3+r%3D0x7f0c0061%7D+at+android.content.res.Resources.loadDrawable%28Resources.java%29

Probably crashing on the 'tab opened in background' toast?

Comments: 

'Mozzila is crashing every time I go to the any link by Open tab in new window.'
tracking-fennec: --- → ?
Crash Signature: [@ android.content.res.Resources$NotFoundException: Resource is not a Drawable (color or path): TypedValue{t=0x1/d=0x7f0c0061 a=3 r=0x7f0c0061} at android.content.res.Resources.loadDrawable(Resources.java)] → [@ android.content.res.Resources$NotFoundException: Resource is not a Drawable (color or path): TypedValue{t=0x1/d=0x7f0c0061 a=3 r=0x7f0c0061} at android.content.res.Resources.loadDrawable(Resources.java)] [@ android.content.res.Resources$NotFoundExcept…
Had a quick look at this. This seems like a device-specific bug. The crash is happening on an ordinary Toast.makeText() call and it seems to be failing to load some drawable from the platform.
Given that "toasts" are informative and mostly not core functionality, do we wrap the code with a try/catch to keep the app from crashing?
Also, can we get a device/OS to reproduce? I'd like to investigate a little, and then make sure any fixes actually work.
Whiteboard: [native-crash] → [native-crash][honeycomb][original Samsung Galaxy Tab]
My GT-P7510 (Galaxy Tab 10" on 3.1) seems unaffected. At least going by the comments and where we show toasts, I am not crashing. Anyone have a GT-P6200?
Tracking for 28 while investigation happens.
MV might will look after stability meeting.
Whiteboard: [native-crash][honeycomb][original Samsung Galaxy Tab] → [native-crash][honeycomb][Samsung Galaxy Tab Plus]
We don't have this device.
No crash using Fx28 beta on my SCH-I800 Samsung Galaxy Tab 7" tablet. I can long tap and "Open in a new tab" and see the toast, without any crash.
Can we get this assigned and an aforementioned try catch patch for the next beta?
Why are we using the application context for UI? http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/home/HomeFragment.java#120

I can't say for sure whether that's the cause, but that seems dangerous.
(In reply to Brian Nicholson (:bnicholson) from comment #12)
> Why are we using the application context for UI?
> http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/home/
> HomeFragment.java#120
> 
> I can't say for sure whether that's the cause, but that seems dangerous.

Yeah, this looks suspicious. It would be nice if we had a device where this bug can be reproduced reliably.
Brian, order a device
Assignee: nobody → bnicholson
tracking-fennec: ? → 28+
Can we correlate that resource id against the ids in the (likely) APK?
We create toasts in all of the places we're using the context ([1], [2], [3]), so we shouldn't use the Application Context anywhere. These UiAsyncTasks should be short-lived enough that a memory leak isn't a problem.

[1] http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/home/HomeFragment.java#157
[2] http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/home/HomeFragment.java#258
[3] http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/home/HomeFragment.java#281
Attachment #8375782 - Flags: review?(mark.finkle)
Comment on attachment 8375782 [details] [diff] [review]
Use Activity context instead of Application context for UI

If we are most worried about the crashes related to Toast and the AsyncTasks are doing DB stuff, we could just pass getActivity() into the Toast call here:
http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/home/HomeFragment.java#157

And leave the rest alone.

Like we do here for the Edit dialog (a UI thing too):
http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/home/HomeFragment.java#163
What changed in this area between 27 and 28?
Comment on attachment 8375782 [details] [diff] [review]
Use Activity context instead of Application context for UI

Change this getActivity() to just use | context | now:
http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/home/HomeFragment.java#163
Attachment #8375782 - Flags: review?(mark.finkle) → review+
(In reply to Nick Alexander :nalexander from comment #15)
> Can we correlate that resource id against the ids in the (likely) APK?

I don't think so: the resource is a built-in Android resource happening in their own libraries.
(In reply to Brian Nicholson (:bnicholson) from comment #20)
> (In reply to Nick Alexander :nalexander from comment #15)
> > Can we correlate that resource id against the ids in the (likely) APK?
> 
> I don't think so: the resource is a built-in Android resource happening in
> their own libraries.

Thanks -- I wondered if that was the case, but no of know way to really check (other than inspecting stacks, etc).
I really hate doing this, but nothing pops out as being suspicious with these Toast.makeText() calls. They're done on the UI thread, and they use the correct context. Not sure what else could be wrong.
Attachment #8375871 - Flags: review?(mark.finkle)
Attachment #8375871 - Flags: review?(mark.finkle) → review+
Comment on attachment 8375871 [details] [diff] [review]
Add try/catch around Toast.makeText to prevent crashes

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Unknown
User impact if declined: Crashes when showing toasts
Testing completed (on m-c, etc.): No testing done; we don't yet have a device to reproduce with. This is a low risk, speculative fix.
Risk to taking this patch (and alternatives if risky): Almost zero risk; just adds a try/catch around existing code.
String or IDL/UUID changes made by this patch: None
Attachment #8375871 - Flags: approval-mozilla-beta?
Comment on attachment 8375871 [details] [diff] [review]
Add try/catch around Toast.makeText to prevent crashes

Please go ahead with uplift so we can get this evaluated in Monday's mobile beta builds and collect feedback next week.
Attachment #8375871 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
https://hg.mozilla.org/mozilla-central/rev/3487558d7e3a
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 30
Early data says this is fixed in crash stats. On Monday we will know for sure.
I would expect this particular crash to be fixed, though I'm concerned that this fix could simply push the crash to other instances of Toast.makeText() that aren't guarded. We should keep a lookout for similar stacktraces that crop up.
According to this crash report [1], a user on Nightly (02/22) is still hitting this crash.

[1] https://crash-stats.mozilla.com/report/index/35446ec9-5b0c-4eed-a37f-2a6062140222
Filed a follow up bug for the still occurring crashes. bug 976375 

Willing to call a two order of magnitude drop in crashes a win.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.