0

I am trying to debug a crash from my Android app, this crash occurs in my NDK armv7a so library, and Google breakpad reports the minidump.

I build breakpad in qemu-system-arm, and minidump_stackwalk works well:

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

but when I try minidump-2-core and gdb, there is only one frame in backtrace:

# ./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

It seems gdb only get one frame, which step is wrong?

zihao chen
  • 1
  • 1
  • Does it work if you also tell gdb which executable crashed?: `gdb your-executable 167.core` – ssbssa Jan 21 '21 at 11:31
  • @ssbssa, I use System.loadLibrary in Java to load my so library, and there is no executable file. I tried to use `add-symbol-file symbol_of_so text_addr` and then `core 167.core`, and the result is the same. – zihao chen Jan 21 '21 at 13:05
  • Isn't java itself the executable in this case? – ssbssa Jan 21 '21 at 16:36
  • I find the sulotion. I pull /system/bin/app_process32 from my Android device as the executable file, and I get the correct backtrace @ssbssa – zihao chen Sep 16 '21 at 08:03

0 Answers0