750965 - crash in libdvm with continuous reloading page after a while

Status: RESOLVED WORKSFORME

(Firefox for Android Graveyard :: General, defect)

Description

[Martijn Wargers (dead)]

Attachment: testcase

I'm seeing this crash on the Samsung Galaxy Nexus.

Steps to reproduce:
- Load the testcase, let it run for at least 5 minutes or so, don't interact with the page at all. Let the doorhanger prompt appear/disappear by itself.

After a while I get this crash then.

This bug was filed from the Socorro interface and is 
report bp-9493a07e-a398-455a-a386-5158d2120501 .
============================================================= 
0 	libdvm.so 	libdvm.so@0x5098e 	

There is also bug 730890 open with a similar stack, but according to bug 730890, comment c51, there are all kinds of unrelated crashes with this stack. That bug seems to be mainly focused on a Flash crash fix, btw.

Comment 1

[Martijn Wargers (dead)]

Actually, a window.location.reload() is already enough to get this crash.

Crashes on the Samsung Galaxy Nexus:
https://crash-stats.mozilla.com/report/index/bp-be31edec-524f-423e-805a-b9ef32120503
0 	libdvm.so 	libdvm.so@0x5098e

On the HTC Desire HD:
https://crash-stats.mozilla.com/report/index/bp-d8b2a466-c12b-425d-89df-b63d62120503
0 	libdvm.so 	dvmAbort 	
1 	libdvm.so 	JNI_CreateJavaVM 	
2 	libdvm.so 	JNI_CreateJavaVM 	
3 	libxul.so 	mozilla::AndroidBridge::HandleGeckoMessage 	jni.h:530
4 	libxul.so 	nsAndroidBridge::HandleGeckoMessage 	widget/android/AndroidBridge.cpp:2025
5 	libxul.so 	NS_InvokeByIndex_P 	xpcom/reflect/xptcall/src/md/unix/xptcinvoke_arm.cpp:194
6 	libxul.so 	XPCWrappedNative::CallMethod 	js/xpconnect/src/XPCWrappedNative.cpp:3117
7 	libxul.so 	XPC_WN_CallMethod 	js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1548
8 	libxul.so 	js::Interpret 	js/src/jscntxtinlines.h:314
9 	libxul.so 	js::RunScript 	js/src/jsinterp.cpp:480
etc...

Also crashes on the Samsung Galaxy SII with a similar stack as the HTC Desire HD.

Since this is very easy to reproduce (just a window.location.reload() on a timer, which quite a few pages are doing probably), reasking for blocking-fennec1.0.

Comment 2

[Kartikaya Gupta (email:[e-mail])]

This is probably due to us OOMing in Java, the OutOfMemoryError getting thrown out and trapped in the AutoLocalJNIFrame, and then the ExceptionOccurred() call in ~AutoLocalJNIFrame throwing another OOM or dying because it can't create a local ref to the jthrowable. At least, so I assume based on the crash stack and the crash stacks of other bugs. Bug 748531 will help a little but the underlying memory leak needs to be fixed for this to be properly fixed. Getting a logcat of the crash might help as I believe dalvik will output counts of objects in memory, and from that it may be more clear where the leak is.

Comment 3

[Martijn Wargers (dead)]

Attachment: catlog from crash

This is a catlog from the crash. This is done on the HTC Desire HD.

Comment 4

[Kartikaya Gupta (email:[e-mail])]

Relevant bit of log that I was talking about is below. We have a lot of ReadWriteDirectByteBuffers in the JNI local ref table. This is probably the same as bug 751588.

05-04 14:37:08.421 W/dalvikvm(16289): ReferenceTable overflow (max=512)
05-04 14:37:08.421 W/dalvikvm(16289): Last 10 entries in JNI local reference table:
05-04 14:37:08.431 W/dalvikvm(16289):   502: 0x406054c8 cls=Ljava/lang/OutOfMemoryError; (28 bytes)
05-04 14:37:08.431 W/dalvikvm(16289):   503: 0x405f8bf0 cls=Ljava/lang/OutOfMemoryError; (28 bytes)
05-04 14:37:08.431 W/dalvikvm(16289):   504: 0x405f3ac8 cls=Ljava/lang/OutOfMemoryError; (28 bytes)
05-04 14:37:08.441 W/dalvikvm(16289):   505: 0x40563d20 cls=Ljava/lang/OutOfMemoryError; (28 bytes)
05-04 14:37:08.441 W/dalvikvm(16289):   506: 0x4060d890 cls=Ljava/lang/OutOfMemoryError; (28 bytes)
05-04 14:37:08.441 W/dalvikvm(16289):   507: 0x405de9e8 cls=Ljava/lang/OutOfMemoryError; (28 bytes)
05-04 14:37:08.441 W/dalvikvm(16289):   508: 0x405eb8e8 cls=Ljava/lang/OutOfMemoryError; (28 bytes)
05-04 14:37:08.441 W/dalvikvm(16289):   509: 0x405f1a90 cls=Ljava/lang/OutOfMemoryError; (28 bytes)
05-04 14:37:08.441 W/dalvikvm(16289):   510: 0x4074c090 cls=Ljava/lang/OutOfMemoryError; (28 bytes)
05-04 14:37:08.451 W/dalvikvm(16289):   511: 0x4074cb48 cls=Ljava/lang/String; (28 bytes)
05-04 14:37:08.451 W/dalvikvm(16289): JNI local reference table summary (512 entries):
05-04 14:37:08.471 W/dalvikvm(16289):   293 of Ljava/nio/ReadWriteDirectByteBuffer; 44B (293 unique)
05-04 14:37:08.471 W/dalvikvm(16289):    92 of Ljava/nio/ReadWriteDirectByteBuffer; 52B (92 unique)
05-04 14:37:08.471 W/dalvikvm(16289):     1 of Ljava/lang/String; 28B
05-04 14:37:08.471 W/dalvikvm(16289):   125 of Ljava/lang/OutOfMemoryError; 28B (125 unique)
05-04 14:37:08.471 W/dalvikvm(16289):     1 of Ljava/lang/OutOfMemoryError; 36B
05-04 14:37:08.471 W/dalvikvm(16289): Memory held directly by tracked refs is 21240 bytes
05-04 14:37:08.471 E/dalvikvm(16289): Failed adding to JNI local ref table (has 512 entries)
05-04 14:37:08.471 I/dalvikvm(16289): "Thread-10" prio=5 tid=9 RUNNABLE
05-04 14:37:08.471 I/dalvikvm(16289):   | group="main" sCount=0 dsCount=0 obj=0x4054bc08 self=0x367570
05-04 14:37:08.471 I/dalvikvm(16289):   | sysTid=16297 nice=0 sched=0/0 cgrp=default handle=732744
05-04 14:37:08.471 I/dalvikvm(16289):   | schedstat=( 39305755652 104193664533 33696 )
05-04 14:37:08.471 I/dalvikvm(16289):   at org.mozilla.gecko.GeckoAppShell.nativeRun(Native Method)
05-04 14:37:08.471 I/dalvikvm(16289):   at org.mozilla.gecko.GeckoAppShell.runGecko(GeckoAppShell.java:493)
05-04 14:37:08.471 I/dalvikvm(16289):   at org.mozilla.gecko.GeckoThread.run(GeckoThread.java:112)
05-04 14:37:08.471 I/dalvikvm(16289): 
05-04 14:37:08.471 E/dalvikvm(16289): VM aborting
05-04 14:37:08.721 D/dalvikvm(16411): GC_CONCURRENT freed 1288K, 35% free 6804K/10439K, external 0K/0K, paused 2ms+9ms
05-04 14:37:09.131 I/ActivityManager( 1360): Process org.mozilla.fennec (pid 16289) has died.

Comment 5

[Kartikaya Gupta (email:[e-mail])]

Just thinking out loud here, but from the output it actually seems like we hit an OOM early on, and since we never clear exceptions in JNI code, they just keep piling up in the local ref table. Also AndroidBridge::TakeScreenshot calls Java_org_mozilla_gecko_GeckoAppShell_allocateDirectBuffer (which returns a local ref to a ReadWriteDirectByteBuffer) before creating the AutoLocalJNIFrame, and that might account for the pile of ReadWriteDirectByteBuffer references in the local ref table. Hopefully bug 748531 will fix both of these; if not, it should at least start reporting more meaningful error messages as it will start logging OOMs when they first happen, rather than waiting for the local ref table to fill up.

Going to leave this open for now and revisit once 748531 is landed.

Comment 6

[Martijn Wargers (dead)]

This seems to be fixed in today's build. I can't reproduce on the Galaxy SII nor on the Galaxy Nexus. marking wfm.