signal 11 (SIGSEGV), fault addr 0000015c是什么错误？怎么解决？

signal 11 (SIGSEGV), fault addr 0000015c是什么错误？怎么解决？

解决方案 »

  1.   

    [Android 调试/测试] 调试错误 signal 11 (SIGSEGV), fault addr 0000015chttp://www.eoeandroid.com/thread-9661-1-1.html调试过程中activity突然退出，打印以下信息，请问是什么原因啊
    01-18 10:18:15.133: INFO/DEBUG(34): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
    01-18 10:18:15.133: INFO/DEBUG(34): Build fingerprint: 'generic/htc_hero/hero/hero:1.5/1.79.482.3/49365:user/release-keys'
    01-18 10:18:15.133: INFO/DEBUG(34): pid: 673, tid: 674  >>> cn.com.application <<<
    01-18 10:18:15.133: INFO/DEBUG(34): signal 11 (SIGSEGV), fault addr 0000015c
    01-18 10:18:15.133: INFO/DEBUG(34):  r0 00000007  r1 00000001  r2 411a183c  r3 0000015c
    01-18 10:18:15.143: INFO/DEBUG(34):  r4 411a183c  r5 001569a0  r6 00000000  r7 00156b48
    01-18 10:18:15.143: INFO/DEBUG(34):  r8 100ffd00  r9 4100aeec  10 4100aed8  fp 00000001
    01-18 10:18:15.143: INFO/DEBUG(34):  ip 00000011  sp 100ffc48  lr ad046f05  pc ad03ee1a  cpsr 00000030
    01-18 10:18:15.473: INFO/DEBUG(34):          #00  pc 0003ee1a  /system/lib/libdvm.so
    01-18 10:18:15.523: INFO/DEBUG(34):          #01  pc 00271d12  /system/lib/libwebcore.so
    01-18 10:18:15.523: INFO/DEBUG(34):          #02  pc 00271e98  /system/lib/libwebcore.so
    01-18 10:18:15.543: INFO/DEBUG(34):          #03  pc 0000e434  /system/lib/libdvm.so
    01-18 10:18:15.543: INFO/DEBUG(34):          #04  pc 00040b0a  /system/lib/libdvm.so
    01-18 10:18:15.553: INFO/DEBUG(34):          #05  pc 00013198  /system/lib/libdvm.so
    01-18 10:18:15.553: INFO/DEBUG(34):          #06  pc 00017b9c  /system/lib/libdvm.so
    01-18 10:18:15.553: INFO/DEBUG(34):          #07  pc 000175e0  /system/lib/libdvm.so
    01-18 10:18:15.563: INFO/DEBUG(34):          #08  pc 000523dc  /system/lib/libdvm.so
    01-18 10:18:15.573: INFO/DEBUG(34):          #09  pc 000523fa  /system/lib/libdvm.so
    01-18 10:18:15.573: INFO/DEBUG(34):          #10  pc 00049774  /system/lib/libdvm.so
    01-18 10:18:15.573: INFO/DEBUG(34):          #11  pc 000497fc  /system/lib/libdvm.so
    01-18 10:18:15.583: INFO/DEBUG(34):          #12  pc 00049b46  /system/lib/libdvm.so
    01-18 10:18:15.593: INFO/DEBUG(34):          #13  pc 000471ca  /system/lib/libdvm.so
    01-18 10:18:15.603: INFO/DEBUG(34):          #14  pc 0000f880  /system/lib/libc.so
    01-18 10:18:15.603: INFO/DEBUG(34):          #15  pc 0000f3f4  /system/lib/libc.so
    01-18 10:18:15.623: INFO/DEBUG(34): stack:
    01-18 10:18:15.623: INFO/DEBUG(34):     100ffc08  100ffc44  
    01-18 10:18:15.623: INFO/DEBUG(34):     100ffc0c  00000000  
    01-18 10:18:15.623: INFO/DEBUG(34):     100ffc10  00000000  
    01-18 10:18:15.623: INFO/DEBUG(34):     100ffc14  001af060  [heap]
    01-18 10:18:15.623: INFO/DEBUG(34):     100ffc18  00000000  
    01-18 10:18:15.623: INFO/DEBUG(34):     100ffc1c  ad0407a9  /system/lib/libdvm.so
    01-18 10:18:15.633: INFO/DEBUG(34):     100ffc20  100ffcc8  
    01-18 10:18:15.633: INFO/DEBUG(34):     100ffc24  00156b48  [heap]
    01-18 10:18:15.633: INFO/DEBUG(34):     100ffc28  001569a0  [heap]
    01-18 10:18:15.633: INFO/DEBUG(34):     100ffc2c  00000001  
    01-18 10:18:15.633: INFO/DEBUG(34):     100ffc30  00000007  
    01-18 10:18:15.633: INFO/DEBUG(34):     100ffc34  ad046f05  /system/lib/libdvm.so
    01-18 10:18:15.633: INFO/DEBUG(34):     100ffc38  411a183c  
    。
    01-18 10:18:17.533: INFO/ActivityManager(81): Process cn.com.application (pid 673) has died.
    01-18 10:18:17.533: INFO/WindowManager(81): WIN DEATH: Window{43715138 cn.com.application/cn.com.application.AppManagerActivity paused=false}
      

  2.   

    Android signal 11 (SIGSEGV), fault addr 00000000http://doyee.blog.163.com/blog/static/1156317201021602729836/
      

  3.   

    Android NDK调试碰到signal 11 (SIGSEGV), fault addr deadbaadhttp://www.sunnyu.com/?p=220
    使用NDK开发的so文件在运行时崩溃，日志中提示
    signal 11 (SIGSEGV), fault addr deadbaad
    然后后面列出了一些寄存器值和pc代码行，stack等信息，根据pc代码行配合 arm-eabi-addr2line可以发掘出错位置所对应的函数名。用法如下;
    arm-eabi-addr2line -f -e libmyjni.so 0×00024039 (输出日志中最上面的pc值，可以回溯最终函数调用顺序)程序中需要有符号信息，不能使用下面的语句将调试符号剔除
    build/prebuilt/linux-x86/arm-eabi-4.2.1/bin/arm-eabi-strip –strip-debug apps/NDKTest/project/libs/armeabi/libmyjni.so
      

  4.   

    Android调试的必杀技——反汇编http://my.unix-center.net/~Simon_fu/?p=527
      

  5.   

    Android 调试.so库文件
    http://blog.csdn.net/netpirate/archive/2010/03/06/5351709.aspx
      

  6.   

    程序CRASH了，看看STACK把，crash在那里了http://blog.csdn.net/OExpress/archive/2010/12/17/6082898.aspx
      

  7.   

    Android的WiFi调试-----不能解析中文名字的AP
    http://developer.lenovomm.com/bbs/archiver/?tid-8924.html
      

  8.   

    使用 Crash 工具分析 Linux dump 文件http://www.ibm.com/developerworks/cn/linux/l-cn-dumpanalyse/index.html?ca=drs-cn-0329
      

  9.   

    android 不再为ndk执行错误打出的一堆不知道什么意思的地址头疼了。 
    http://hi.baidu.com/dean_wang/blog/item/e83b2df210a375d77831aa46.html终于找到如何解读ndk运行直接挂掉之后的错误地址，以后jni执行崩溃后除了加一堆的LOG就有新的方法调试 了。如果logcat再一次打出如下的错误：12-1022:20:04.839 I/DEBUG   (  551):************************************************
    12-1022:20:04.839 I/DEBUG   (  551):Build fingerprint:'generic/sdk/generic/:1.5/CUPCAKE/150240:eng/test-keys'
    12-1022:20:04.839 I/DEBUG   (  551): pid:1003, tid:1003  >>> com.example <<<
    12-1022:20:04.849 I/DEBUG   (  551): signal 11(SIGSEGV), fault addr 00000004
    12-1022:20:04.849 I/DEBUG   (  551):  r0 00000000  r1 0019ed48  r2 00000001  r3 0019eae4
    12-1022:20:04.859 I/DEBUG   (  551):  r4 0019ea9c  r5 0019ed48  r6 001935b0  r7 0000a9d0
    12-1022:20:04.859 I/DEBUG   (  551):  r8 00000001  r9 0019eae4  10804df39c  fp 0019ea9c
    12-1022:20:04.869 I/DEBUG   (  551):  ip 00000071  sp beb6f4a8  lr 8041d8d9  pc 8041cc6c  cpsr 00000030
    12-1022:20:04.948 I/DEBUG   (  551):          #00  pc 0000e3b4  /system/lib/libdvm.so
    12-1022:20:04.948 I/DEBUG   (  551): stack:
    12-1022:20:04.948 I/DEBUG   (  551):     beb6f468  00000000
    12-1022:20:04.959 I/DEBUG   (  551):     beb6f46c  0019ede3  [heap]
    12-1022:20:04.959 I/DEBUG   (  551):     beb6f470  00000002
    ...如果是以前，遇到这种情况是头疼的，不知道在哪挂掉了，之前只能在代码里面一句一句加log定位。
     无意中发现了 http://source.android.com/这是个让人惊喜的网站。主要面向系统程序员；里面大量介绍了android系统移植；（暂时不关我什么事）；但是里面有篇文章介绍了如果debug native：http://source.android.com/porting/debugging_native.html很好。耐心读完 只见最关键一步在 Use the "stack" tool to convert these addresses to files and line numbers 这个就郁闷了。什么是 "stack" tool？ 去sdk以及 各个地方好像都找不到。外事不决问google；找到http://code.google.com/p/android-ndk-stacktrace-analyzer/  OK。具体怎么使用介绍的很详细。 
      

  10.   

    Android native crash log分析
    http://wiki.impjq.net/doku.php?id=android:android-jni:android-ndk-stacktrace-analyzer
      

  11.   

    Android signal 11 (SIGSEGV) Native Code crash 跟踪 
    http://apps.hi.baidu.com/share/detail/22489855
      

  12.   

    好难找问题所在啊！一会是这个SO模块报错，一会是另外一个SO模块报错。
    整了几天了还是找不到问题所在！！！
    其实是一段蛮简单的代码！！！
      

  13.   

    把malloc( )++++free( )成对使用的情况换成一个预分配的数组，情况好很多啊！难道malloc( )++++free( )会造成内存碎片，使得free( )执行失败什么的！！！
      

  14.   


    原来是对malloc( )函数的认识不足造成的，malloc( )函数是按字节数来分配内存空间的，所以分配INT的内存指针要记得在内存空间大小上乘以4才是正确的。以前没乘以4所以存在很多越界跟非法的操作！！！所以出现了上面的错误。
    真的是技术都在细节啊！！！
      

  15.   

    今天又出现这样的CRASH。看来解决之道还很漫长啊！
      

  16.   

    觉得跨线程调用JNIENV上下文环境很容易出问题！！！
      

  17.   

    Signal 11 while compiling the kernelhttp://www.bitwizard.nl/sig11/ANSWER
    Signal 11, or officially know as "segmentation fault", means that the program accessed a memory location that was not assigned. That's usually a bug in the program. So if you're writing your own program, that's the most likely cause. However, this FAQ will concentrate on the possibilities besides that. 
      

  18.   


    Supporting JNI callbacks on a different thread / looking up JNIEnv correctly
    http://www.experts-exchange.com/Programming/Languages/Java/Q_21281132.html
     need to find a way to make a callback from C++ code to Java (through JNI) where the callback is on a different thread than the original call from Java that started the processing.Let me explain that a bit more.  Here's the sequence in psuedo code:Java:
        startOperation("myCallback") ; // This is a JNI call
        
    void myCallback()
    {
    }JNI/C++:
         JNICALL JNI_startOperation(callbackName)
         {
              call-to-C-code-to-do-lots-of-stuff(&c_callback, data) ;
         }     c_callback(data)
         {
               // Need to call back to "myCallback" in Java from here.
         }My current solution is in "JNI_startOperation" I store the JNIEnv* object I've been passed, record it with the callback and when the C++ callback occurs I retrieve it and use it to callback to Java through someting like: jenv->CallVoidMethod().  So far all is fine.  The problem is if the callback is on a different thread than the original JNI_startOperation() this approach is no good because the cached JNIEnv* (I assume) is thread-specific and crashes the JVM when I try to use it.So what I'm looking for is the proper way to look up this JNIEnv* object rather than caching it.  I see methods about enumerating JVM's etc. in the JNI interface, but I'm not sure how to use them.Anyone understand this stuff and can help walk me through it?Doug
      

  19.   

    多线程间不能随便去使用JNIENV这个NDK公共对象指针Chapter 8 Additional JNI Features
    http://java.sun.com/docs/books/jni/html/other.html
      

  20.   


    8.1.1 Constraints
    There are certain constraints that you must keep in mind when writing native methods that are to run in a multithreaded environment. By understanding and programming within these constraints, your native methods will execute safely no matter how many threads simultaneously execute a given native method. For example: A JNIEnv pointer is only valid in the thread associated with it. You must not pass this pointer from one thread to another, or cache and use it in multiple threads. The Java virtual machine passes a native method the same JNIEnv pointer in consecutive invocations from the same thread, but passes different JNIEnv pointers when invoking that native method from different threads. Avoid the common mistake of caching the JNIEnv pointer of one thread and using the pointer in another thread. 
    Local references are valid only in the thread that created them. You must not pass local references from one thread to another. You should always convert local references to global references whenever there is a possibility that multiple threads may use the same reference. 
      

  21.   

    当JNI遇到多线程－－java对象如何被C++中的多个线程访问? 
    http://blog.csdn.net/hust_liuX/article/details/1460486
      

  22.   

    Chapter 10 Traps and Pitfalls
    http://java.sun.com/docs/books/jni/html/pitfalls.html#29161
    10.14 Using the JNIEnv across Threads
    The JNIEnv pointer, passed as the first argument to every native method, can only be used in the thread with which it is associated. It is wrong to cache the JNIEnv interface pointer obtained from one thread, and use that pointer in another thread. Section 8.1.4 explains how you can obtain the JNIEnv interface pointer for the current thread.
      

  23.   

    8.1.4 Obtaining a JNIEnv Pointer in Arbitrary Contexts
    We explained earlier that a JNIEnv pointer is only valid in its associated thread. This is generally not a problem for native methods because they receive the JNIEnv pointer from the virtual machine as the first argument. Occasionally, however, it may be necessary for a piece of native code not called directly from the virtual machine to obtain the JNIEnv interface pointer that belongs to the current thread. For example, the piece of native code may belong to a "callback" function called by the operating system, in which case the JNIEnv pointer will probably not be available as an argument. You can obtain the JNIEnv pointer for the current thread by calling the AttachCurrentThread function of the invocation interface: 
     JavaVM *jvm; /* already set */
     
     f()
     {
         JNIEnv *env;
         (*jvm)->AttachCurrentThread(jvm, (void **)&env, NULL);
         ... /* use env */
     }When the current thread is already attached to the virtual machine, Attach-Current-Thread returns the JNIEnv interface pointer that belongs to the current thread. There are many ways to obtain the JavaVM pointer: by recording it when the virtual machine is created, by querying for the created virtual machines using JNI_GetCreatedJavaVMs, by calling the JNI function GetJavaVM inside a regular native method, or by defining a JNI_OnLoad handler. Unlike the JNIEnv pointer, the JavaVM pointer remains valid across multiple threads so it can be cached in a global variable. Java 2 SDK release 1.2 provides a new invocation interface function GetEnv so that you can check whether the current thread is attached to the virtual machine, and, if so, to return the JNIEnv pointer that belongs to the current thread. GetEnv and AttachCurrentThread are functionally equivalent if the current thread is already attached to the virtual machine. 
      

  24.   

    JNIEnv与jobject对象跨线程使用要特别处理！！！
      

  25.   

    也遇到这个问题，就是load so出现的，不知道如何解决啊！！！！！
      

  26.   

    01-18 13:55:08.898: A/libc(31273): Fatal signal 11 (SIGSEGV) at 0x48d20000 (code=2)
    01-18 13:55:08.914: I/DEBUG(28313): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
    01-18 13:55:08.914: I/DEBUG(28313): Build fingerprint: 'Android/full_aries/aries:4.0.3/IML74K/eng.root.20120104.223924:userdebug/test-keys'
    01-18 13:55:08.914: I/DEBUG(28313): pid: 31273, tid: 31276  >>> com.xxx.mcamera <<<
    01-18 13:55:08.914: I/DEBUG(28313): signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 48d20000
    01-18 13:55:08.914: I/DEBUG(28313):  r0 48d20000  r1 48b12040  r2 00019bc0  r3 00000000
    01-18 13:55:08.914: I/DEBUG(28313):  r4 408b19b8  r5 00000001  r6 0000001c  r7 0000001c
    01-18 13:55:08.914: I/DEBUG(28313):  r8 41168000  r9 00000000  10 017f0cd8  fp 408afc58
    01-18 13:55:08.914: I/DEBUG(28313):  ip 408aaff0  sp 100ffe00  lr 408736c1  pc 40038b84  cpsr 20000010
    01-18 13:55:08.914: I/DEBUG(28313):  d0  0000000000000000  d1  0000000000000000
    01-18 13:55:08.914: I/DEBUG(28313):  d2  0000000000000000  d3  0000000000000000
    01-18 13:55:08.914: I/DEBUG(28313):  d4  0000000000000000  d5  0000000000000000
    01-18 13:55:08.914: I/DEBUG(28313):  d6  0000000000000000  d7  0000000000000000
    01-18 13:55:08.914: I/DEBUG(28313):  d8  0000000000000000  d9  0000000000000000
    01-18 13:55:08.914: I/DEBUG(28313):  d10 0000000000000000  d11 0000000000000000
    01-18 13:55:08.914: I/DEBUG(28313):  d12 0000000000000000  d13 0000000000000000
    01-18 13:55:08.914: I/DEBUG(28313):  d14 0000000000000000  d15 0000000000000000
    01-18 13:55:08.914: I/DEBUG(28313):  d16 0000000000000000  d17 3ff0000000000000
    01-18 13:55:08.914: I/DEBUG(28313):  d18 41b4f43b54000000  d19 0000000000000000
    01-18 13:55:08.914: I/DEBUG(28313):  d20 0000000000000000  d21 0000000000000000
    01-18 13:55:08.914: I/DEBUG(28313):  d22 0000000000000000  d23 0000000000000000
    01-18 13:55:08.914: I/DEBUG(28313):  d24 0000000000000000  d25 0000000000000000
    01-18 13:55:08.914: I/DEBUG(28313):  d26 0000000000000000  d27 0000000000000000
    01-18 13:55:08.914: I/DEBUG(28313):  d28 0000000000000000  d29 0000000000000000
    01-18 13:55:08.914: I/DEBUG(28313):  d30 0000000000000000  d31 0000000000000000
    01-18 13:55:08.914: I/DEBUG(28313):  scr 80000012
    01-18 13:55:09.074: I/DEBUG(28313):          #00  pc 0000db84  /system/lib/libc.so (memcpy)
    01-18 13:55:09.078: I/DEBUG(28313):          #01  pc 0007b6be  /system/lib/libdvm.so (_Z20dvmMarkImmuneObjectsPKc)
    01-18 13:55:09.078: I/DEBUG(28313):          #02  pc 00043604  /system/lib/libdvm.so (_Z18dvmHeapMarkRootSetv)
    01-18 13:55:09.078: I/DEBUG(28313):          #03  pc 000333f8  /system/lib/libdvm.so (_Z25dvmCollectGarbageInternalPK6GcSpec)
    01-18 13:55:09.078: I/DEBUG(28313):          #04  pc 0007ba40  /system/lib/libdvm.so
    01-18 13:55:09.078: I/DEBUG(28313):          #05  pc 0005f656  /system/lib/libdvm.so
    01-18 13:55:09.078: I/DEBUG(28313):          #06  pc 00012be4  /system/lib/libc.so (__thread_entry)
    01-18 13:55:09.082: I/DEBUG(28313):          #07  pc 00012738  /system/lib/libc.so (pthread_create)
    01-18 13:55:09.082: I/DEBUG(28313): code around pc:
    01-18 13:55:09.082: I/DEBUG(28313): 40038b64 3a000009 f5d1f080 f5d1f0c0 f5d1f100  ...:............
    01-18 13:55:09.082: I/DEBUG(28313): 40038b74 f421020d f421420d f5d1f100 e2522040  ..!..B!.....@ R.
    01-18 13:55:09.082: I/DEBUG(28313): 40038b84 f400022d f400422d 2afffff8 e2822040  -...-B.....*@ ..
    01-18 13:55:09.082: I/DEBUG(28313): 40038b94 e2522020 3a000003 f421020d e2522020    R....:..!.  R.
    01-18 13:55:09.082: I/DEBUG(28313): 40038ba4 f400022d 2afffffb e2822020 e3120010  -......*  ......
    01-18 13:55:09.082: I/DEBUG(28313): code around lr:
    01-18 13:55:09.082: I/DEBUG(28313): 408736a0 f8dc6ed9 1a50e030 020eebc2 6f580a01  .n..0.P.......Xo
    01-18 13:55:09.082: I/DEBUG(28313): 408736b0 6e1b0a12 00920089 18591840 edf6f7a2  [email protected].....
    01-18 13:55:09.082: I/DEBUG(28313): 408736c0 199e6823 1084f8d3 42916b32 f8c3bf38  #h......2k.B8...
    01-18 13:55:09.082: I/DEBUG(28313): 408736d0 35012084 6d1a6823 d3d94295 81f0e8bd  . .5#h.m.B......
    01-18 13:55:09.082: I/DEBUG(28313): 408736e0 0003e32a b5104803 68004478 f7b73074  *....H..xD.ht0..
    01-18 13:55:09.082: I/DEBUG(28313): memory map around addr 48d20000:
    01-18 13:55:09.082: I/DEBUG(28313): 48d1d000-48d20000 /dev/ashmem/dalvik-bitmap-2 (deleted)
    01-18 13:55:09.082: I/DEBUG(28313): 48d20000-48d22000 /datadata/ com.xxx.mcamera /adapterlib/libandroidadapter.so
    01-18 13:55:09.082: I/DEBUG(28313): 48d22000-48d23000 /datadata/ com.xxx.mcamera /data/adapterlib/libandroidadapter.so
    01-18 13:55:09.082: I/DEBUG(28313): stack:
    01-18 13:55:09.086: I/DEBUG(28313):     100ffdc0  4088b3eb  /system/lib/libdvm.so
    01-18 13:55:09.086: I/DEBUG(28313):     100ffdc4  0c8b8700  
    01-18 13:55:09.086: I/DEBUG(28313):     100ffdc8  0000fa00  
    01-18 13:55:09.086: I/DEBUG(28313):     100ffdcc  4003be98  /system/lib/libc.so
    01-18 13:55:09.086: I/DEBUG(28313):     100ffdd0  d84a2e1c  
    01-18 13:55:09.086: I/DEBUG(28313):     100ffdd4  00000005  
    01-18 13:55:09.086: I/DEBUG(28313):     100ffdd8  000003e8  
    01-18 13:55:09.086: I/DEBUG(28313):     100ffddc  000003e8  
    01-18 13:55:09.086: I/DEBUG(28313):     100ffde0  00000000  
    01-18 13:55:09.086: I/DEBUG(28313):     100ffde4  d84a2e1c  
    01-18 13:55:09.086: I/DEBUG(28313):     100ffde8  00000005  
    01-18 13:55:09.086: I/DEBUG(28313):     100ffdec  100ffe9c  
    01-18 13:55:09.086: I/DEBUG(28313):     100ffdf0  0187c748  [heap]
    01-18 13:55:09.086: I/DEBUG(28313):     100ffdf4  408b19b8  
    01-18 13:55:09.086: I/DEBUG(28313):     100ffdf8  df0027ad  
    01-18 13:55:09.086: I/DEBUG(28313):     100ffdfc  00000000  
    01-18 13:55:09.086: I/DEBUG(28313): #00 100ffe00  48d1d000  /dev/ashmem/dalvik-bitmap-2 (deleted)
    01-18 13:55:09.086: I/DEBUG(28313):     100ffe04  408736c1  /system/lib/libdvm.so
    01-18 13:55:09.086: I/DEBUG(28313): #01 100ffe08  0187c6e8  [heap]
    01-18 13:55:09.086: I/DEBUG(28313):     100ffe0c  0187c6e8  [heap]
    01-18 13:55:09.086: I/DEBUG(28313):     100ffe10  408aaf90  /system/lib/libdvm.so
    01-18 13:55:09.089: I/DEBUG(28313):     100ffe14  fffffe4c  
    01-18 13:55:09.089: I/DEBUG(28313):     100ffe18  7fffffff  
    01-18 13:55:09.089: I/DEBUG(28313):     100ffe1c  4083b608  /system/lib/libdvm.so
    01-18 13:55:09.886: I/BootReceiver(219): Copying /data/tombstones/tombstone_02 to DropBox (SYSTEM_TOMBSTONE)
    01-18 13:55:09.898: D/Zygote(160): Process 31273 terminated by signal (11)
    01-18 13:55:09.906: I/ActivityManager(219): Process com.xxx.mcamera (pid 31273) has died.