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

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: Overlays, defect)

Description

[Cristina Madaras, QA [:CristinaM]]

This bug was filed from the Socorro interface and is 
report bp-a9a98dd0-ac50-427f-aac4-732972141208.
=============================================================

0	libxul.so	Java_org_mozilla_gecko_GeckoAppShell_reportJavaCrash	widget/android/AndroidJNI.cpp
1	libmozglue.so	Java_org_mozilla_gecko_GeckoAppShell_reportJavaCrash	mozglue/android/jni-stubs.inc
Ø 2	libdvm.so	libdvm.so@0x17ef6	
Ø 3	dalvik-LinearAlloc (deleted)	dalvik-LinearAlloc (deleted)@0x205662	
Ø 4	dalvik-heap (deleted)	dalvik-heap (deleted)@0x55c8a6	
Ø 5	libdvm.so	libdvm.so@0x49801	
Ø 6	data@[e-mail]@classes.dex	data@[e-mail]@classes.dex@0x288af3	
7	libmozglue.so	Java_org_mozilla_gecko_GeckoAppShell_dispatchMemoryPressure	mozglue/android/jni-stubs.inc
Ø 8	dalvik-LinearAlloc (deleted)	dalvik-LinearAlloc (deleted)@0x205662	
Ø 9	libdvm.so	libdvm.so@0x497b7	
Ø 10	dalvik-heap (deleted)	dalvik-heap (deleted)@0x55c8a6	
Ø 11	libdvm.so	libdvm.so@0x4efb7	
Ø 12	dalvik-LinearAlloc (deleted)	dalvik-LinearAlloc (deleted)@0x205662	
Ø 13	data@[e-mail]@classes.dex	data@[e-mail]@classes.dex@0x12dbca	
Ø 14	dalvik-heap (deleted)	dalvik-heap (deleted)@0x55c8a6	
Ø 15	libdvm.so	libdvm.so@0x180be	
Ø 16	libdvm.so	libdvm.so@0x1d10a	
Ø 17	framework.odex	framework.odex@0x430596	
Ø 18	libdvm.so	libdvm.so@0xa5372	
Ø 19	libdvm.so	libdvm.so@0x2219a	
Ø 20	libdvm.so	libdvm.so@0x2210a	
Ø 21	dalvik-LinearAlloc (deleted)	dalvik-LinearAlloc (deleted)@0x2dc2	
Ø 22	libdvm.so	libdvm.so@0x2107e	
Ø 23	libdvm.so	libdvm.so@0x1d292	
Ø 24	core.odex	core.odex@0xa3e52	
Ø 25	dalvik-heap (deleted)	dalvik-heap (deleted)@0x8a5d76	
Ø 26	dalvik-LinearAlloc (deleted)	dalvik-LinearAlloc (deleted)@0x2040a6	
Ø 27	dalvik-heap (deleted)	dalvik-heap (deleted)@0x3b7796e	
Ø 28	framework.odex	framework.odex@0x4301a0	
Ø 29	libdvm.so	libdvm.so@0xa9b16	
Ø 30	dalvik-LinearAlloc (deleted)	dalvik-LinearAlloc (deleted)@0x19defe	
Ø 31	libdvm.so	libdvm.so@0x1cdea	
Ø 32	libdvm.so	libdvm.so@0x1ce62	
Ø 33	libdvm.so	libdvm.so@0x1cd0a	
Ø 34	libdvm.so	libdvm.so@0x1cd32	
Ø 35	libdvm.so	libdvm.so@0x1cd62	
Ø 36	libdvm.so	libdvm.so@0x1cd86	
Ø 37	libdvm.so	libdvm.so@0x7f9ab	
Ø 38	core.odex	core.odex@0xb2810	
Ø 39	core.odex	core.odex@0xb2810	
Ø 40	core.odex	core.odex@0xb27c8	
Ø 41	libdvm.so	libdvm.so@0xa9b16	
Ø 42	libdvm.so	libdvm.so@0x70c69	
Ø 43	dalvik-heap (deleted)	dalvik-heap (deleted)@0x414f6	
Ø 44	libdvm.so	libdvm.so@0xa560a	
Ø 45	libdvm.so	libdvm.so@0x70c69	
Ø 46	dalvik-heap (deleted)	dalvik-heap (deleted)@0x16c706	
Ø 47	dalvik-LinearAlloc (deleted)	dalvik-LinearAlloc (deleted)@0x1aea1a	
Ø 48	libdvm.so	libdvm.so@0x20dee	
Ø 49	libdvm.so	libdvm.so@0xa560a	
Ø 50	dalvik-heap (deleted)	dalvik-heap (deleted)@0x8866	
Ø 51	libdvm.so	libdvm.so@0xa560a	
Ø 52	libdvm.so	libdvm.so@0x68a71	
Ø 53	dalvik-heap (deleted)	dalvik-heap (deleted)@0x8866	
Ø 54	libdvm.so	libdvm.so@0x54d57	
Ø 55	libdvm.so	libdvm.so@0xa560a	
Ø 56	dalvik-heap (deleted)	dalvik-heap (deleted)@0x414d6	
Ø 57	libdvm.so	libdvm.so@0x54d57	
Ø 58	dalvik-heap (deleted)	dalvik-heap (deleted)@0x414d6	
Ø 59	libdvm.so	libdvm.so@0x97bd5	
Ø 60	libdvm.so	libdvm.so@0x48ca1	
Ø 61	libdvm.so	libdvm.so@0x5524b	
Ø 62	dalvik-heap (deleted)	dalvik-heap (deleted)@0x414d6	
Ø 63	dalvik-heap (deleted)	dalvik-heap (deleted)@0x308ce	
Ø 64	dalvik-heap (deleted)	dalvik-heap (deleted)@0x414d6	
Ø 65	libdvm.so	libdvm.so@0x55287	
Ø 66	dalvik-heap (deleted)	dalvik-heap (deleted)@0x414d6	
Ø 67	dalvik-heap (deleted)	dalvik-heap (deleted)@0x308ce	
Ø 68	libdvm.so	libdvm.so@0x6d677	
Ø 69	libdvm.so	libdvm.so@0x6c679	
Ø 70	dalvik-LinearAlloc (deleted)	dalvik-LinearAlloc (deleted)@0x9ba8e	
Ø 71	framework.odex	framework.odex@0x575a2e	
Ø 72	libdvm.so	libdvm.so@0x6c679	
Ø 73	dalvik-LinearAlloc (deleted)	dalvik-LinearAlloc (deleted)@0x9b71a	
Ø 74	dalvik-LinearAlloc (deleted)	dalvik-LinearAlloc (deleted)@0x9b706	
Ø 75	libdvm.so	libdvm.so@0x6c679	
Ø 76	dalvik-LinearAlloc (deleted)	dalvik-LinearAlloc (deleted)@0x2dd6	
Ø 77	core.odex	core.odex@0x29409e	
Ø 78	dalvik-LinearAlloc (deleted)	dalvik-LinearAlloc (deleted)@0x2dc2	
Ø 79	libdvm.so	libdvm.so@0xa560a	
Ø 80	dalvik-heap (deleted)	dalvik-heap (deleted)@0xc576	
Ø 81	core.odex	core.odex@0x2fb8c0	
Ø 82	libdvm.so	libdvm.so@0x5ff51	
Ø 83	dalvik-LinearAlloc (deleted)	dalvik-LinearAlloc (deleted)@0x2dc2	
Ø 84	dalvik-heap (deleted)	dalvik-heap (deleted)@0xc576	
Ø 85	libdvm.so	libdvm.so@0xa560a	
Ø 86	libdvm.so	libdvm.so@0x89dd5	
Ø 87	dalvik-heap (deleted)	dalvik-heap (deleted)@0x66ff26	
Ø 88	dalvik-heap (deleted)	dalvik-heap (deleted)@0xc576	
Ø 89	dalvik-heap (deleted)	dalvik-heap (deleted)@0xc576	
Ø 117	libutils.so	libutils.so@0x1dc6f	
Ø 118	libutils.so	libutils.so@0x1dd63	
Ø 119	libutils.so	libutils.so@0x1dd85	
Ø 120	app_process	app_process@0xdd5	
Ø 121	app_process	app_process@0xccb	
Ø 122	app_process	app_process@0x1026	
Ø 123	libandroid_runtime.so	libandroid_runtime.so@0xd77b6	
Ø 124	app_process	app_process@0xb32	
Ø 125	app_process	app_process@0xb32	
Ø 126	libc.so	libc.so@0x1508f

Steps:
1. Navigate to a page;
2. Open the custom menu and choose Share;
3. Choose Add to Nightly.

Notes: I'm able to reproduce this only with Samsung Galaxy R (Android 2.3.4)

Comment 1

[Richard Newman [:rnewman]]

Here's the stack:

Java Stack Trace 	

android.content.res.Resources$NotFoundException: Resource is not a Drawable (color or path): TypedValue{t=0x1/d=0x7f0200c3 a=-1 r=0x7f0200c3}
	at android.content.res.Resources.loadDrawable(Resources.java:1907)
	at android.content.res.TypedArray.getDrawable(TypedArray.java:653)
        ...
	at android.view.LayoutInflater.inflate(LayoutInflater.java:276)
	at com.android.internal.policy.impl.PhoneWindow.setContentView(PhoneWindow.java:215)
	at android.app.Activity.setContentView(Activity.java:1663)
	at org.mozilla.gecko.overlays.ui.ShareDialog.onCreate(ShareDialog.java:138)

Comment 2

[:Margaret Leibovic]

I can only reproduce this on Nightly (not on Aurora, nor my local fx-team build), so I wonder if it's caused by the split APK work.

Looking at the crash stack, this is caused by inflating overlay_share_dialog.xml. Looking into the drawables used there, I found that there's only one version of share_overlay_background.9.png, and it's in drawable-xhdpi. Could that be the problem?

rnewman, is there a way to make a build locally that only targets API level 9?

Also, are there any tests for the share overlay? I'm assuming no, because I would think this would cause bustage if this was tested in tbpl.

Comment 3

[Nick Alexander :nalexander [he/him]]

This does look like a split APK thing (well, a resource constrained thing).  We cull the xhdpi resources in resource constrained, I think, so we won't have this resource at runtime.

Comment 4

[Richard Newman [:rnewman]]

> Looking at the crash stack, this is caused by inflating
> overlay_share_dialog.xml. Looking into the drawables used there, I found
> that there's only one version of share_overlay_background.9.png, and it's in
> drawable-xhdpi. Could that be the problem?

Yes. We should make an hdpi version of that image.

(aapt is supposed to be smart enough to include the xhdpi version if there is no smaller one. Alas, in reality it doesn't work.)


> rnewman, is there a way to make a build locally that only targets API level
> 9?

Yup:

ac_add_options --with-android-min-sdk=9
ac_add_options --with-android-max-sdk=10
ac_add_options --with-android-version=9
ac_add_options --enable-android-resource-constrained

 
> Also, are there any tests for the share overlay? I'm assuming no, because I
> would think this would cause bustage if this was tested in tbpl.

Bug 1061410.

Comment 5

[:Margaret Leibovic]

Looking through the comments in bug 1044947, I don't see anything explaining the reasoning behind this xhdpi background.

cktiching, is there a reason why you only created an xhdpi version of share_overlay_background.9.png? Would it work for me to just copy this same image over to the hdpi directory, or do we need to create a new image?

Comment 6

[:Margaret Leibovic]

Attachment: MozReview Request: bz://1108564/margaret

Comment 7

[:Margaret Leibovic]

/r/1597 - Bug 1108564 - Move share_overlay_background.9.png to hdpi directory to avoid crashes on resource-constrained builds

Pull down this commit:

hg pull review -r 55095639ff6df78723fe71dc564f2222807f3bd7

Comment 8

[:Margaret Leibovic]

This patch fixes the crash. I don't think we actually need multiple image resolutions for this background drawable, but I can update the patch if I'm wrong.

Comment 9

[Richard Newman [:rnewman]]

https://reviewboard.mozilla.org/r/1595/#review989

Ship It!

Comment 10

[:Margaret Leibovic]

https://hg.mozilla.org/integration/fx-team/rev/2aa6d44a4e71

Comment 11

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/2aa6d44a4e71

Comment 12

[Chris Kitching [:ckitching]]

(In reply to :Margaret Leibovic from comment #5)
> Looking through the comments in bug 1044947, I don't see anything explaining
> the reasoning behind this xhdpi background.
> 
> cktiching, is there a reason why you only created an xhdpi version of
> share_overlay_background.9.png? Would it work for me to just copy this same
> image over to the hdpi directory, or do we need to create a new image?

Seems I'm late to the party again: sorry Margaret, that always seems to happen when you needinfo me :/.

I don't remember there being any special reason for doing that. Forgetfulness, probably.
Thanks for cleaning up my mess!

Comment 13

[Richard Newman [:rnewman]]

Comment on attachment 8538752 [details]
MozReview Request: bz://1108564/margaret

Approval Request Comment
[Feature/regressing bug #]:
  Bug 948509 (fx35)

[User impact if declined]:
  Crashes in constrained builds when using share overlay.

[Describe test coverage new/current, TBPL]:
  None yet.

[Risks and why]: 
  This is a zero-risk patch (adding a missing asset). There's some chance that splitapk stuff will hop ahead to 36, in which case there's a risk of forgetting this. Might as well get it in now.

[String/UUID change made/needed]:
  None.

Comment 14

[:Margaret Leibovic]

(In reply to Chris Kitching [:ckitching] from comment #12)
> (In reply to :Margaret Leibovic from comment #5)
> > Looking through the comments in bug 1044947, I don't see anything explaining
> > the reasoning behind this xhdpi background.
> > 
> > cktiching, is there a reason why you only created an xhdpi version of
> > share_overlay_background.9.png? Would it work for me to just copy this same
> > image over to the hdpi directory, or do we need to create a new image?
> 
> Seems I'm late to the party again: sorry Margaret, that always seems to
> happen when you needinfo me :/.
> 
> I don't remember there being any special reason for doing that.
> Forgetfulness, probably.
> Thanks for cleaning up my mess!

Thanks for the reply! You're not late at all, I was just eager to land something :)

Comment 15

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/1548fb0d8aa0

Comment 16

[Cristina Madaras, QA [:CristinaM]]

Verified as fixed in builds:
Firefox for Android 37.0a1 (2014-12-12)
Firefox for Android 36.0a2 (2014-12-12)
Device: Samsung Galaxy R (Android 2.3.4)
I am not able to reproduce this crash on Firefox for Android 35 Beta 6, so I will mark this as verified fixed.

Comment 18

[:Margaret Leibovic]

Attachment: MozReview Request: Bug 1108564 - Move share_overlay_background.9.png to hdpi directory to avoid crashes on resource-constrained builds