본문 바로가기

Linux

android rebooting dalvik error bug

Originally Posted by steven676 View Post
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:

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)
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.