如何解决当 gdb 带有来自 minidump-2-core 的核心时,回溯不正确
我正在尝试从我的 Android 应用程序调试崩溃,此崩溃发生在我的 NDK armv7a so 库中,并且 Google breakpad 报告了小型转储。
我在 qemu-system-arm 中构建了 breakpad,并且 minidump_stackwalk 运行良好:
# ./breakpad/src/processor/minidump_stackwalk 1674a7b6-19d1-455d-e1b8f69d-d856b136.dmp >167.txt 2>log.txt
# cat 167.txt
Operating system: Android
0.0.0 Linux 4.4.78-perf+ #2 SMP PREEMPT Thu May 28 21:34:52 CST 2020 armv8l
cpu: arm
ARMv1 Qualcomm part(0x51008010) features: half,thumb,fastmult,vfpv2,edsp,neon,vfpv3,tls,vfpv4,idiva,idivt
8 cpus
GPU: UNKNowN
Crash reason: SIGSEGV /SEGV_MAPERR
Crash address: 0x0
Process uptime: not available
Thread 133 (crashed)
0 libxxxxxxx.so + 0x3dfe566
r0 = 0x00000007 r1 = 0xc82a8db8 r2 = 0xc5368d81 r3 = 0xcd94bfba
r4 = 0x00000000 r5 = 0x00000000 r6 = 0xc82a8db8 r7 = 0x92b06c92
r8 = 0xc02b1ca0 r9 = 0xa8ebe5cc r10 = 0x961a45a8 r12 = 0xc7a6be90
fp = 0xa8ebe480 sp = 0x6f1fa818 lr = 0xc5648567 pc = 0xc5648566
Found by: given as instruction pointer in context
1 libxxxxxxx.so + 0x4b9c08d
sp = 0x6f1fa838 pc = 0xc63e608f
Found by: stack scanning
2 libxxxxxxx.so + 0x4bae305
sp = 0x6f1fa848 pc = 0xc63f8307
Found by: stack scanning
(more)
但是当我尝试 minidump-2-core 和 gdb 时,回溯中只有一帧:
# ./minidump-2-core 1674a7b6-19d1-455d-e1b8f69d-d856b136.dmp >167.core
# gdb -c 167.core
Core was generated by `com.xxx.xx '.
#0 0xc5648566 in ?? ()
[Current thread is 1 (LWP 6371)]
(gdb) bt
#0 0xc5648566 in ?? ()
Backtrace stopped: prevIoUs frame identical to this frame (corrupt stack?)
(gdb) p $sp
$1 = (void *) 0x6f1fa818
gdb好像只得到一帧,哪一步错了?
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。