Home/ Questions/Q 8176081
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-06T23:01:29+00:00

I am getting a segfault in the native part of my android app, in

  • 0

I am getting a segfault in the native part of my android app, in the moment a void function returns to its caller. To visualize better, I put a log statement at the end of the callee function, and one in the caller function, right after the call to the callee (sorry for the pun).
In the logcat, the first message is printed, and the second not (the app crashes).

Thinking about a possible memory corruption I decided to activate malloc debug (giving “setprop libc.debug.malloc 10” in adb shell). Then, i get this in the logcat right after the log message from the end of the callee function:

D/MyApp - NativeSide(12778):  I am the callee function and I am about to return!
E/libc    (12778): *** FREE CHECK: buffer 0x82869900 corrupted 16 bytes before allocation
E/libc    (12778): call stack:
E/libc    (12778):  0: 8000e3ea
E/libc    (12778):  1: 8000e49c
E/libc    (12778):  2: 8000e4e2
E/libc    (12778):  3: 8000e540
E/libc    (12778):  4: afd14ccc
E/libc    (12778):  5: 81258188
E/libc    (12778):  6: 81258188
E/libc    (12778):  7: 81258188
E/libc    (12778):  8: 81258188
E/libc    (12778):  9: 81258188
E/libc    (12778): 10: 81258188
E/libc    (12778): 11: 81258188
E/libc    (12778): 12: 81258188
E/libc    (12778): 13: 81258188
E/libc    (12778): 14: 81258188
E/libc    (12778): 15: 81258188
E/libc    (12778): 16: 81258188
E/libc    (12778): 17: 81258188
E/libc    (12778): 18: 81258188
E/libc    (12778): 19: 81258188

I couldn’t find any information on how to decipher this output. The numbers shown at each line are changing at every app launch. I hope there’s a way to use this information as a clue on where the corruption happens, as I can’t find it from the code. I also tried building the native libraries with the “-fstack-check flag, but I couldn’t say if I got more informations in the log (it seems not but I might have missed them), or whether I need to do other things to get them.

Also, here’s the stack dump, coming after the “FREE CHECK:” message.

I/DEBUG   (12311): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG   (12311): Build fingerprint: 'google/soju/crespo:2.3/GRH55/79397:user/release-keys'
I/DEBUG   (12311): pid: 12778, tid: 12907  >>> com.ntrack.tuner <<<
I/DEBUG   (12311): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadbaad
I/DEBUG   (12311):  r0 deadbaad  r1 45ea374c  r2 00000027  r3 00000000
I/DEBUG   (12311):  r4 00000080  r5 45ea374c  r6 8003422e  r7 45ea37b4
I/DEBUG   (12311):  r8 45da4000  r9 a811eca5  10 00100000  fp 00000001
I/DEBUG   (12311):  ip ffffffff  sp 45ea3738  lr 8000f623  pc 8000f650  cpsr 20000030
I/DEBUG   (12311):  d0  3f9664f48406d639  d1  3f8226e3e96e8495
I/DEBUG   (12311):  d2  3faba1ba1bb34201  d3  0000000000000000
I/DEBUG   (12311):  d4  3d7943379e56fd24  d5  3d8f940585cd5f95
I/DEBUG   (12311):  d6  3f2cf2145b888497  d7  3f2cf214636d85f8
I/DEBUG   (12311):  d8  0000000000000000  d9  0000000000000000
I/DEBUG   (12311):  d10 0000000000000000  d11 0000000000000000
I/DEBUG   (12311):  d12 0000000000000000  d13 0000000000000000
I/DEBUG   (12311):  d14 0000000000000000  d15 0000000000000000
I/DEBUG   (12311):  scr 20000010
I/DEBUG   (12311):

Anything, a suggestion on the typical things to check or just the way to make use of the malloc debug informations would be of great help, thanks!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    To me, this:

    a segfault in the native part of my android app, in the moment a void function returns to its caller.

    means stack corruption (more than heap corruption). What state is stored on the stack of this function you’re returning from (and from every function it calls ..)?

    The call stack output you’re seeing should be the address of each function on the stack at the time the corruption was detected. You’ll need to know what address your library was loaded at to map those back to a symbol in your .so. (I think this question will help: How to use addr2line in Android)

    The fact that 81258188 repeats off the top of the stack dump also suggest that you might’ve blown out the bottom of the stack (by recursing too many times). If you’re not aware of any intentional recursion in your code, then figuring out where your library was loaded and mapping that back to your code could be useful.

    • 0