signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadd00d
#00 pc 0x50f8e /system/lib/libdvm.so (dvmAbort+89)
#01 pc 0x59ee1 /system/lib/libdvm.so (dvmLinearAlloc(Object*, unsigned int)+64)
#02 pc 0x76a7b /system/lib/libdvm.so (???)
#03 pc 0x76d77 /system/lib/libdvm.so (dvmDefineClass(DvmDex*, char const*, Object*)+10)
#04 pc 0x71583 /system/lib/libdvm.so (???)
#05 pc 0x30c0c /system/lib/libdvm.so (???)
#06 pc 0x343dc /system/lib/libdvm.so (dvmInterpret(Thread*, Method const*, JValue*)+184)
#07 pc 0x6d109 /system/lib/libdvm.so (dvmCallMethodV(Thread*, Method const*, Object*, bool, JValue*, std::__va_list)+284)
#08 pc 0x6d12d /system/lib/libdvm.so (dvmCallMethod(Thread*, Method const*, Object*, JValue*, ...)+20)
#09 pc 0x76e69 /system/lib/libdvm.so (dvmFindClassNoInit(char const*, Object*)+108)
#10 pc 0x6216b /system/lib/libdvm.so (???)
#11 pc 0x62287 /system/lib/libdvm.so (???)
#12 pc 0x65a6d /system/lib/libdvm.so (dvmVerifyCodeFlow(VerifierData*)+9760)
#13 pc 0x68c91 /system/lib/libdvm.so (???)
#14 pc 0x68ce3 /system/lib/libdvm.so (dvmVerifyClass(ClassObject*)+42)
#15 pc 0x7704d /system/lib/libdvm.so (dvmInitClass+116)
#16 pc 0x742d1 /system/lib/libdvm.so (???)
#17 pc 0x30c0c /system/lib/libdvm.so (???)
#18 pc 0x343dc /system/lib/libdvm.so (dvmInterpret(Thread*, Method const*, JValue*)+184)
#19 pc 0x6ce39 /system/lib/libdvm.so (dvmInvokeMethod(Object*, Method const*, ArrayObject*, ArrayObject*, ClassObject*, bool)+344)
#20 pc 0x73b19 /system/lib/libdvm.so (???)
#21 pc 0x30c0c /system/lib/libdvm.so (???)
#22 pc 0x343dc /system/lib/libdvm.so (dvmInterpret(Thread*, Method const*, JValue*)+184)
#23 pc 0x6ce39 /system/lib/libdvm.so (dvmInvokeMethod(Object*, Method const*, ArrayObject*, ArrayObject*, ClassObject*, bool)+344)
#24 pc 0x7431b /system/lib/libdvm.so (???)
#25 pc 0x30c0c /system/lib/libdvm.so (???)
#26 pc 0x343dc /system/lib/libdvm.so (dvmInterpret(Thread*, Method const*, JValue*)+184)
#27 pc 0x6d109 /system/lib/libdvm.so (dvmCallMethodV(Thread*, Method const*, Object*, bool, JValue*, std::__va_list)+284)
#28 pc 0x554af /system/lib/libdvm.so (???)
#29 pc 0x48c6b /system/lib/libandroid_runtime.so (???)
#30 pc 0x4a81f /system/lib/libandroid_runtime.so (android::AndroidRuntime::start(char const*, char const*)+394)
#31 pc 0xf0d /system/bin/app_process (???)
java.lang.Throwable:
******* Java stack for JNI crash *******
at dalvik.system.DexFile.defineClass(Native Method)
at dalvik.system.DexFile.loadClassBinaryName(DexFile.java:195)
at dalvik.system.DexPathList.findClass(DexPathList.java:315)
at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:58)
at java.lang.ClassLoader.loadClass(ClassLoader.java:501)
at java.lang.ClassLoader.loadClass(ClassLoader.java:461)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:511)
at com.lily.dexLoader.invokeStaticMethod(SourceFile:70)
at com.lily.sdk.Web.<init>(SourceFile:77)
......
I can not reproduce this crash through my android app, but the monitor system reports this kind of crash many times.
It is not clear whether the dex is broken or the system dalvik is not stable.
Does anyone has any experience on this kind of loadClass crash?
If the VM detects a serious problem, it will send diagnostics to the log, and abort. The VM in the version of Android you're using crashes itself by attempting to write to a read-only location (0xdeadd00d).
Looking at the stack trace, the last thing before dvmAbort() is dvmLinearAlloc(). Looking at a recent source file, the VM will abort in that function if it runs out of memory to allocate, or if it's unable to change the permissions on a page while in a special debug mode where pages are aggressively marked read-only. It's almost certainly the former. Looking at the logcat output would tell you for sure.
Assuming you're running out of memory, I'd guess you're running an old version of Android (<= gingerbread), where the "linear alloc" buffer was under-sized. This region of memory is used to hold class meta-data, such as tables of methods and fields, but not the data itself (which is why it can be marked read-only to help hunt for memory trashers). The only way to avoid the problem is to restructure the classes.
You can read more about the problem, and a solution deployed by Facebook engineers, in this blog post.