970081 - 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)

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Kevin Brosnan [Ex-Mozilla]]

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)

Comment 2

[Aaron Train [:aaronmt]]

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.'

Comment 3

[Lucas Rocha (:lucasr)]

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.

Comment 4

[Mark Finkle (:mfinkle) (use needinfo?)]

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?

Comment 5

[Mark Finkle (:mfinkle) (use needinfo?)]

Also, can we get a device/OS to reproduce? I'd like to investigate a little, and then make sure any fixes actually work.

Comment 6

[Aaron Train [:aaronmt]]

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?

Comment 7

[Lukas Blakk [:lsblakk] use ?needinfo]

Tracking for 28 while investigation happens.

Comment 8

[Kevin Brosnan [Ex-Mozilla]]

MV might will look after stability meeting.

Comment 9

[Kevin Brosnan [Ex-Mozilla]]

We don't have this device.

Comment 10

[Mark Finkle (:mfinkle) (use needinfo?)]

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.

Comment 11

[Aaron Train [:aaronmt]]

Can we get this assigned and an aforementioned try catch patch for the next beta?

Comment 12

[Brian Nicholson (:bnicholson)]

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.

Comment 13

[Lucas Rocha (:lucasr)]

(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.

Comment 14

[Brad Lassey [:blassey] (use needinfo?)]

Brian, order a device

Comment 15

[Nick Alexander :nalexander [he/him]]

Can we correlate that resource id against the ids in the (likely) APK?

Comment 16

[Brian Nicholson (:bnicholson)]

Attachment: Use Activity context instead of Application context for UI

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

Comment 17

[Mark Finkle (:mfinkle) (use needinfo?)]

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

Comment 18

[Aaron Train [:aaronmt]]

What changed in this area between 27 and 28?

Comment 19

[Mark Finkle (:mfinkle) (use needinfo?)]

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

Comment 20

[Brian Nicholson (:bnicholson)]

(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.

Comment 21

[Nick Alexander :nalexander [he/him]]

(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).

Comment 22

[Brian Nicholson (:bnicholson)]

Attachment: Add try/catch around Toast.makeText to prevent crashes

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.

Comment 23

[Brian Nicholson (:bnicholson)]

First (probably unrelated) fix: https://hg.mozilla.org/integration/fx-team/rev/3487558d7e3a

Comment 24

[Brian Nicholson (:bnicholson)]

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

Comment 25

[Lukas Blakk [:lsblakk] use ?needinfo]

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.

Comment 26

[Brian Nicholson (:bnicholson)]

https://hg.mozilla.org/releases/mozilla-beta/rev/5f96175bb23d

Comment 27

[:Gijs (he/him)]

https://hg.mozilla.org/mozilla-central/rev/3487558d7e3a

Comment 28

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/5f96175bb23d

Comment 29

[Kevin Brosnan [Ex-Mozilla]]

Early data says this is fixed in crash stats. On Monday we will know for sure.

Comment 30

[Brian Nicholson (:bnicholson)]

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.

Comment 31

[Aaron Train [:aaronmt]]

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

Comment 32

[Kevin Brosnan [Ex-Mozilla]]

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.