android底层crash问题

时间:2021-10-15 00:56:15
#01  pc 0001dbcc  /system/lib/libdvm.so (dvmPlatformInvoke+112)
#02  pc 0004e123  /system/lib/libdvm.so (dvmCallJNIMethod(unsigned int const*, JValue*, Method const*, Thread*)+398)
#03  pc 00026fe0  /system/lib/libdvm.so
#04  pc 0002dfa0  /system/lib/libdvm.so (dvmMterpStd(Thread*)+76)
#05  pc 0002b638  /system/lib/libdvm.so (dvmInterpret(Thread*, Method const*, JValue*)+184)
#06  pc 00060581  /system/lib/libdvm.so (dvmCallMethodV(Thread*, Method const*, Object*, bool, JValue*, std::__va_list)+336)
#07  pc 000605a5  /system/lib/libdvm.so (dvmCallMethod(Thread*, Method const*, Object*, JValue*, ...)+20)
#08  pc 0005528b  /system/lib/libdvm.so
#09  pc 0000d170  /system/lib/libc.so (__thread_entry+72)
#10  pc 0000d308  /system/lib/libc.so (pthread_create+240)

底层crash,eclipse logcat中打印出以上信息,请问有谁知道如 (dvmPlatformInvoke+112)表示什么意思? 数字112代表什么?

8 个解决方案

#1


前后的日志是啥?
这种问题估计一般都只能找google了

#2


dvmPlatformInvoke+112 表示 函数 和它里面的 偏移地址吧

#3


引用 2 楼 nj_dobetter 的回复:
dvmPlatformInvoke+112 表示 函数 和它里面的 偏移地址吧


如果是偏移地址的话,能不能从这个偏移地址算出具体行数?

#4


不懂,帮顶下

#5


引用 3 楼 lynchyong 的回复:
Quote: 引用 2 楼 nj_dobetter 的回复:

dvmPlatformInvoke+112 表示 函数 和它里面的 偏移地址吧


如果是偏移地址的话,能不能从这个偏移地址算出具体行数?

这个需要编译产生的符号表才能定位到具体代码的行数,一般只有厂商才有。
如果你是自己编译的ROM,符号表在编译后目录的symbol目录下。

#6


做了什么操作出现这样的错误了呢?

#7


可以看一下crash log最后有没有其他报错信息。
如果有的话,可以定位crash代码的具体位置。
希望对你有帮助。

#8


推荐看下threadingtest,它是白盒级别的崩溃分析工具,可以捕捉和分析和可视化展示崩溃发生前的程序的执行的详细的执行路径(逻辑走向和条件、分支走向),相比腾讯bugly,testin等的的基于崩溃日志分析方法,可以直接的给出崩溃的原因,帮助开发和测试迅速的修复缺陷。可以参照这个:http://www.teststars.cc/news03.html

#1


前后的日志是啥?
这种问题估计一般都只能找google了

#2


dvmPlatformInvoke+112 表示 函数 和它里面的 偏移地址吧

#3


引用 2 楼 nj_dobetter 的回复:
dvmPlatformInvoke+112 表示 函数 和它里面的 偏移地址吧


如果是偏移地址的话,能不能从这个偏移地址算出具体行数?

#4


不懂,帮顶下

#5


引用 3 楼 lynchyong 的回复:
Quote: 引用 2 楼 nj_dobetter 的回复:

dvmPlatformInvoke+112 表示 函数 和它里面的 偏移地址吧


如果是偏移地址的话,能不能从这个偏移地址算出具体行数?

这个需要编译产生的符号表才能定位到具体代码的行数,一般只有厂商才有。
如果你是自己编译的ROM,符号表在编译后目录的symbol目录下。

#6


做了什么操作出现这样的错误了呢?

#7


可以看一下crash log最后有没有其他报错信息。
如果有的话,可以定位crash代码的具体位置。
希望对你有帮助。

#8


推荐看下threadingtest,它是白盒级别的崩溃分析工具,可以捕捉和分析和可视化展示崩溃发生前的程序的执行的详细的执行路径(逻辑走向和条件、分支走向),相比腾讯bugly,testin等的的基于崩溃日志分析方法,可以直接的给出崩溃的原因,帮助开发和测试迅速的修复缺陷。可以参照这个:http://www.teststars.cc/news03.html