[Nook Color Android Development] steven676:
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:

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)

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_kernel/commit/4711e673aea88ce380499478ce6bcd4591534c2e

https://github.com/keyodi/nook_kernel/commit/7a312d4a75bd109dbe42536487955fd567ca18af

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/kernel/common/+/2a90957f2cfc2bf0b705a62a97830cf0d42a5a40^!/

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.