Does the calculator work on a freshly booted ROM on this build?
Nothing all that interesting in dmesg, which surprises me a little (was that everything? I'd have expected a SEGV to be noted in the dmesg, at least). The logcat contains this tidbit:
which suggests heap corruption. I note that this crash is in a
binder thread -- binder has a kernel-space component, so I wonder if
there are fixes we need to backport from a newer kernel into our 2.6.32
...
EDIT: The only significant differences between our 2.6.32 and 3.0 kernel binder code would seem to be two commits from kernel.org 2.6.32-stable:
https://github.com/keyodi/nook_kerne...6bcd4591534c2e
https://github.com/keyodi/nook_kerne...955fd567ca18af
Both of those are in the Android android-3.4 tree, but it looks like that tree also has a fix to a bug introduced by 7a312d4:
https://android.googlesource.com/ker...0d42a5a40%5E!/
I guess we should cherry-pick that into our 2.6.32 (or just revert the two other commits) and see whether that fixes the problem.
EDIT 2: Nope, I still get crashes with signatures showing heap corruption with that patch applied. It doesn't always seem to begin in the same thread or process either, which suggests a kernel bug, but probably kills my theory that the bug is in the binder code specifically. That said, we should still probably take that patch or revert the two commits.
Nothing all that interesting in dmesg, which surprises me a little (was that everything? I'd have expected a SEGV to be noted in the dmesg, at least). The logcat contains this tidbit:
Code:
F/libc ( 1316): Fatal signal 11 (SIGSEGV) at 0xece1eb71 (code=1), thread 10914 (Binder_C) I/DEBUG ( 1079): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** I/DEBUG ( 1079): Build fingerprint: 'bn/bn_encore/encore:4.1.1/JRO03C/228551:user/release-keys' I/DEBUG ( 1079): pid: 1316, tid: 10914, name: UNKNOWN >>> system_server <<< I/DEBUG ( 1079): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr ece1eb71 [...] I/DEBUG ( 1079): backtrace: I/DEBUG ( 1079): #00 pc 00037b9c /system/lib/libdvm.so I/DEBUG ( 1079): #01 pc 00029d6c /system/lib/libdvm.so (dvmHeapBitmapScanWalk(HeapBitmap*, void (*)(Object*, void*, void*), void*)+96) I/DEBUG ( 1079): #02 pc 0003802c /system/lib/libdvm.so (dvmHeapScanMarkedObjects()+36) I/DEBUG ( 1079): #03 pc 0002a088 /system/lib/libdvm.so (dvmCollectGarbageInternal(GcSpec const*)+148) I/DEBUG ( 1079): #04 pc 0002a868 /system/lib/libdvm.so (dvmMalloc(unsigned int, int)+416) I/DEBUG ( 1079): #05 pc 0006756d /system/lib/libdvm.so I/DEBUG ( 1079): #06 pc 000495e7 /system/lib/libdvm.so I/DEBUG ( 1079): #07 pc 0006c58b /system/lib/libandroid_runtime.so (GraphicsJNI::allocateJavaPixelRef(_JNIEnv*, SkBitmap*, SkColorTable*)+130) I/DEBUG ( 1079): #08 pc 000691a3 /system/lib/libandroid_runtime.so I/DEBUG ( 1079): #09 pc 0001e0b0 /system/lib/libdvm.so (dvmPlatformInvoke+112) I/DEBUG ( 1079): #10 pc 0004d0cf /system/lib/libdvm.so (dvmCallJNIMethod(unsigned int const*, JValue*, Method const*, Thread*)+390) I/DEBUG ( 1079): #11 pc 000274e0 /system/lib/libdvm.so I/DEBUG ( 1079): #12 pc 0002bdc4 /system/lib/libdvm.so (dvmInterpret(Thread*, Method const*, JValue*)+180) I/DEBUG ( 1079): #13 pc 0005f831 /system/lib/libdvm.so (dvmCallMethodV(Thread*, Method const*, Object*, bool, JValue*, std::__va_list)+272) I/DEBUG ( 1079): #14 pc 0004c779 /system/lib/libdvm.so I/DEBUG ( 1079): #15 pc 00049e8d /system/lib/libandroid_runtime.so I/DEBUG ( 1079): #16 pc 000653bf /system/lib/libandroid_runtime.so I/DEBUG ( 1079): #17 pc 0001428d /system/lib/libbinder.so (android::BBinder::transact(unsigned int, android::Parcel const&, android::Parcel*, unsigned int)+60) I/DEBUG ( 1079): #18 pc 00016e39 /system/lib/libbinder.so (android::IPCThreadState::executeCommand(int)+520) I/DEBUG ( 1079): #19 pc 00017261 /system/lib/libbinder.so (android::IPCThreadState::joinThreadPool(bool)+184) I/DEBUG ( 1079): #20 pc 0001afe1 /system/lib/libbinder.so I/DEBUG ( 1079): #21 pc 00010f4b /system/lib/libutils.so (android::Thread::_threadLoop(void*)+114) I/DEBUG ( 1079): #22 pc 000476ab /system/lib/libandroid_runtime.so (android::AndroidRuntime::javaThreadShell(void*)+66) I/DEBUG ( 1079): #23 pc 00010ab1 /system/lib/libutils.so I/DEBUG ( 1079): #24 pc 00012c24 /system/lib/libc.so (__thread_entry+48) I/DEBUG ( 1079): #25 pc 0001238c /system/lib/libc.so (pthread_create+180)
EDIT: The only significant differences between our 2.6.32 and 3.0 kernel binder code would seem to be two commits from kernel.org 2.6.32-stable:
https://github.com/keyodi/nook_kerne...6bcd4591534c2e
https://github.com/keyodi/nook_kerne...955fd567ca18af
Both of those are in the Android android-3.4 tree, but it looks like that tree also has a fix to a bug introduced by 7a312d4:
https://android.googlesource.com/ker...0d42a5a40%5E!/
I guess we should cherry-pick that into our 2.6.32 (or just revert the two other commits) and see whether that fixes the problem.
EDIT 2: Nope, I still get crashes with signatures showing heap corruption with that patch applied. It doesn't always seem to begin in the same thread or process either, which suggests a kernel bug, but probably kills my theory that the bug is in the binder code specifically. That said, we should still probably take that patch or revert the two commits.