I decoded the stack trace using passion-symbols-189904, which is also GRK39F but appears to be from a different device. I'm hoping libandroid_runtime.so
is essentially unchanged. The trace is:
Stack Trace:
RELADDR FUNCTION FILE:LINE
0003f5e4 android::getNumRows(_JNIEnv*, _jobject*)+12 /usr/local/google/buildbot/repo_clients/goog/frameworks/base/core/jni/android_database_CursorWindow.cpp:508
00017e34 dvmPlatformInvoke+116 /usr/local/google/buildbot/repo_clients/goog/dalvik/vm/arch/arm/CallEABI.S:243
0004968c dvmCallJNIMethod_virtualNoRef+52 /usr/local/google/buildbot/repo_clients/goog/dalvik/vm/Jni.c:1790
0001d034 dalvik_mterp+12 /usr/local/google/buildbot/repo_clients/goog/dalvik/vm/mterp/out/InterpAsm-armv7-a-neon.S:10017
000220e4 dvmMterpStd+140 /usr/local/google/buildbot/repo_clients/goog/dalvik/vm/mterp/Mterp.c:105
00020fdc dvmInterpret+272 /usr/local/google/buildbot/repo_clients/goog/dalvik/vm/interp/Interp.c:1345
0005fc40 dvmCallMethodV+300 /usr/local/google/buildbot/repo_clients/goog/dalvik/vm/interp/Stack.c:529
0005fe54 dvmCallMethod+20 /usr/local/google/buildbot/repo_clients/goog/dalvik/vm/interp/Stack.c:434
00055fec callMethod+88 /usr/local/google/buildbot/repo_clients/goog/dalvik/vm/alloc/HeapWorker.c:244
00056068 doHeapWork+52 /usr/local/google/buildbot/repo_clients/goog/dalvik/vm/alloc/HeapWorker.c:307
000561fa heapWorkerThreadStart+310 /usr/local/google/buildbot/repo_clients/goog/dalvik/vm/alloc/HeapWorker.c:437
Assuming the symbols match, it's calling a CursorWindow function from a finalizer. You can't see the managed stack trace, so it's hard to say which finalizer. Looking at line 508 here, I'd guess "window" is NULL.
The fact that it's happening in a finalizer probably explains why it happens in slightly different places each time -- the timing is tied to garbage collection.
I would guess that there's something with a Cursor
that you could be closing explicitly but aren't, so the finalizer is doing (and fumbling) the work.