704467 - Crash in AwesomeBar @ mozalloc_abort | __swrite | dexDataMapAlloc

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect, P5)

Description

[Ludovic Hirlimann [:Usul]]

This bug was filed from the Socorro interface and is 
report bp-baaf58be-ef0d-46e6-9976-0541a2111121 .
=============================================================

Comment 1

[Ludovic Hirlimann [:Usul]]

I don't remember doing anything special to get that crash.

Comment 2

[Aaron Train [:aaronmt]]

Naoki, dupe?

Comment 3

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

The crash signature is the same : bug 680615; but that crash had happened in XUL, not native.  Ludovic, do you recall any door hangers appearing or steps to repro possibly based on bug 680615?

Comment 4

[Ludovic Hirlimann [:Usul]]

(In reply to Naoki Hirata :nhirata from comment #3)
> The crash signature is the same : bug 680615; but that crash had happened in
> XUL, not native.  Ludovic, do you recall any door hangers appearing or steps
> to repro possibly based on bug 680615?

No I don't sorry.

Comment 5

[Cristian Nicolae (:xti)]

Attachment: crash log

This crashed occurred for several times on the latest Nightly build. It seems that it happens after Fennec recovers from another crash, for example like the one from bug 704129.

https://crash-stats.mozilla.com/report/index/bp-20aa3ee8-dfd3-4393-bc68-24cd02111123
https://crash-stats.mozilla.com/report/index/bp-d7437aa8-6a3a-42d6-89b3-870d32111123

--
Mozilla/5.0 (Android;Linux armv7l;rv:11.0a1)Gecko/20111122
Firefox/11.0a1 Fennec/11.0a1
Devices: Samsung Galaxy Nexus S
OS: Android 2.3.4

Comment 6

[Scoobidiver (away)]

I changed the summary to differentiate it from crashes in 8.0 and 9.0 where the stack traces are different.
It appears in 10.0a1 and 11.0a1:
https://crash-stats.mozilla.com/report/list?range_value=30&range_unit=days&signature=mozalloc_abort%20|%20__swrite%20|%20dexDataMapAlloc

It might be related to bug 691279.

Comment 7

[Scoobidiver (away)]

It's #1 top crasher in 11.0a1.

Comment 9

[Scoobidiver (away)]

As stack traces slightly differ, I rename the summary to its original name.

Crash reasons are various:
* RuntimeException:
"Unable to pause activity {org.mozilla.fennec/org.mozilla.fennec.App}: java.lang.NullPointerException
at android.app.ActivityThread.performPauseActivity(ActivityThread.java:2358)"
"Screen size of (480,800) larger than maximum texture size of 0"
"Screen size of (480,854) larger than maximum texture size of 0"
"Screen size of (540,960) larger than maximum texture size of 0"

* NullPointerException:
"at org.mozilla.gecko.AboutHomeContent.onConfigurationChanged(AboutHomeContent.java:214)"
"at org.mozilla.gecko.GeckoApp.onPrepareOptionsMenu(GeckoApp.java:487)"

* IllegalArgumentException:
"View not attached to window manager"

* CursorIndexOutOfBoundsException:
"Index -1 requested, with a size of 4"

* IllegalStateException:
"get field slot from row 1 col 5 failed"
"couldn't move cursor to position 1"
"The content of the adapter has changed but ListView did not receive a notification. Make sure the content of your adapter is not modified from a background thread, but only from the UI thread. [in ListView(2131427345, class android.widget.ListView) with Adapter(class org.mozilla.gecko.AwesomeBarTabs$AwesomeBarCursorAdapter)]"

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I hit the same crash with a Nightly build from 121207 three times in a row today. The last two crashes occurred directly on start-up. The first crash I triggered by entering 'about:fennec' in the awesomebar. But tapping on 'c' didn't add the letter to the URL. Fennec simply crashed.

Crash report: bp-6e22e694-0ca0-43ff-b3f7-5e2eb2111220

To simplify querying on Bugzilla here the full stack:

0 	libmozalloc.so 	mozalloc_abort 	memory/mozalloc/mozalloc_abort.cpp:66
1 	libc.so 	__swrite 	
2 		@0x3d 	
3 	libdvm.so 	dexDataMapAlloc 	
4 	libmozutils.so 	Java_org_mozilla_gecko_GeckoAppShell_callObserver 	other-licenses/android/APKOpen.cpp:257
5 		@0xbeb60436 	
6 	libmozutils.so 	Java_org_mozilla_gecko_GeckoAppShell_removeObserver 	other-licenses/android/APKOpen.cpp:258
7 	libdvm.so 	dvmPlatformInvoke 	
8 	libdvm.so 	dvmCallJNIMethod_general 	
9 	libdvm.so 	dvmResolveNativeMethod 	
10 	libdvm.so 	dvmAsmSisterStart 	
11 	libdvm.so 	dvmMterpStd 	
12 	libdvm.so 	dvmInterpret 	
13 	libdvm.so 	dvmInvokeMethod 	
14 	libdvm.so 	dvmFreeDexOrJar 	
15 	libdvm.so 	dvmAsmSisterStart 	
16 	libdvm.so 	dvmMterpStd 	
17 	libdvm.so 	dvmInterpret 	
18 	libdvm.so 	dvmCallMethodV 	
19 	libdvm.so 	JNI_CreateJavaVM 	
20 	libandroid_runtime.so 	_ZN7android14AndroidRuntime6onExitEi 	
21 	libandroid_runtime.so 	_ZN7android14AndroidRuntime5startEPKcb 	
22 	app_process 	app_process@0xccb 	
23 	app_process 	app_process@0x1026 	
24 	libandroid_runtime.so 	AES_decrypt 	
25 	app_process 	app_process@0xb32 	
26 	app_process 	app_process@0xb32 	
27 	libc.so 	__libc_init 	
28 		@0xffffffe2 	
29 	app_process 	app_process@0x32 	
30 	app_process 	app_process@0xb1e

Comment 11

[alex_mayorga]

A crash from last week FWIW
https://crash-stats.mozilla.com/report/index/bp-7eb15c19-a1a5-44b9-9c9c-608fc2111226

Comment 12

[Doug Turner (:dougt)]

Attachment: try

Everywhere I see the use of ExpandableListView.ExpandableListContextMenuInfo, I see it being tested before being used.  It may be that the there are some buggy roms where we are seeing a valid ListView but a null as the extend menu info or something??

I think you attempted fixing this in bug 712627, but it looks like the crash is still present.

I'll look around for a better fix, but I think we should bandaide and follow up here.  This bug is 10% of all crashes in Native Fennec.

Comment 13

[Doug Turner (:dougt)]

Comment on attachment 587949 [details] [diff] [review]
try

over to wes, he wrote this code

Comment 14

[Wesley Johnston (:wesj)]

Comment on attachment 587949 [details] [diff] [review]
try

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

I don't mind putting the bandaide in. Maybe you could also add it to the AdapterView below it as well?

I seriously doubt this is what's going on here though, and none of the info I see in here seem to point to it either.... This code SHOULD only run when you long tap on an item in your history.

::: mobile/android/base/AwesomeBar.java
@@ +403,5 @@
> +            
> +            try {
> +                info = (ExpandableListView.ExpandableListContextMenuInfo) menuInfo;
> +            } catch (ClassCastException e) {
> +                Log.e(e, "bad menuInfo");

Log.e(LOGTAG, "Unable to get menuInfo", e);

Comment 15

[Doug Turner (:dougt)]

Attachment: patch v.2

without try/catch

Comment 16

[Doug Turner (:dougt)]

Attachment: patch v.2

Comment 17

[Wesley Johnston (:wesj)]

Comment on attachment 588044 [details] [diff] [review]
patch v.2

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

::: mobile/android/base/AwesomeBar.java
@@ +399,5 @@
>          String title = "";
>  
>          if (view == (ListView)findViewById(R.id.history_list)) {
> +            if (! (menuInfo instanceof ExpandableListView.ExpandableListContextMenuInfo)) {
> +                Log.e(LOGTAG, "menuInfo is no ExpandableListContextMenuInfo");

s/no/not

Comment 18

[Doug Turner (:dougt)]

https://hg.mozilla.org/mozilla-central/rev/c98283f80ae7

Comment 19

[Scoobidiver (away)]

I renamed the bug summary to match the patch content as there are still crashes with this crash signature after the patch landing.
See comment 9 for different Java exceptions.

Currently same Java exceptions are broken down with different crash signatures.
I think all Fennec Native crash reports containing a Java exception in App Notes should have the Java exception as the crash signature. See bp-c2e3924f-b9cb-448a-b04f-8a7602120111 for instance.

Comment 20

[Scoobidiver (away)]

Here are two crash reports with the Java exception that is supposed to be fixed by the patch:
bp-87c065ef-d01b-4801-97b9-cb5d12120113 before the patch
bp-1ae3f282-03a7-4921-a26e-9e4a22120115 after the patch

Comment 21

[Doug Turner (:dougt)]

[@ mozalloc_abort | __swrite | dexDataMapAlloc] is bogus.  Look at the java exception in the App Notes (yeah, it sucks being there, but whatever)

file new bug please.

Comment 22

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

(In reply to Scoobidiver from comment #20)
> Here are two crash reports with the Java exception that is supposed to be
> fixed by the patch:
> bp-87c065ef-d01b-4801-97b9-cb5d12120113 before the patch
> bp-1ae3f282-03a7-4921-a26e-9e4a22120115 after the patch

That is bug 713056. Let's take the crash signature over to that bug.

Comment 23

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

mozalloc_abort | __swrite | dexDataMapAlloc seems to appear for a number of varying java crashes.  

There's a bug that is filed for separating the java crashes out to it's own field for Socorro.

Comment 24

[Alex Keybl [:akeybl]]

Comment on attachment 588044 [details] [diff] [review]
patch v.2

[Triage Comment]
Mobile only - approved for Aurora.

Comment 25

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

https://hg.mozilla.org/releases/mozilla-aurora/rev/7a463122041a