I'm trying to debug a native C++ App that is crashing using lldb
I also have a sleep(5) at the start of android_main so that I can attach to my app in that time, if that matters
After attaching the app is paused/stopped. So, I use continue
But the process is immediately stopped after using continue and throws a SIGSEGV
(lldb) continue
Process 4158 resuming
Process 4158 stopped
* thread #19, name = 'com.example.app', stop reason = signal SIGSEGV: invalid address (fault address: 0x0)
frame #0: 0x00007cefe26282c8
-> 0x7cefe26282c8: movq (%rcx), %rdx
0x7cefe26282cb: movq %rdx, 0x18a0(%rax)
0x7cefe26282d2: movl 0x8(%rcx), %ecx
0x7cefe26282d5: movl %ecx, 0x18a8(%rax)
After another continue, the app just exits/crashes
(lldb) continue
Process 4158 exited with status = 11 (0x0000000b)
How do I fix this and just continue execution as normal?
Your app crashed because the register rcx was supposed to hold the address of some object, but in fact held a value that was not in readable memory. That's what SIGSEGV means - a request was made to access memory that couldn't be fulfilled. You can't "continue execution as normal" since the program didn't get some data it needs, so it doesn't have a way to move forward. If you knew the value that SHOULD have been in rcx, you could set rcx to the right value, and then continue. But what you really have to do is figure out why that value was bad, fix the code, rebuild and rerun.
Related
I would like to debug a system framework running on an Android device.
In particular, GpsLocationProvider sometimes stops for a while, and I would like to know what it is doing. I found the class contains a android.os.Handler that gets messages posted to it, to communicate between threads. Sometimes it takes minutes between a message is sent, and Handler.handleMessage is called. I interpret that the thread belonging to the Handler's Looper is busy.
I would like to attach a debugger, pause that thread, and see what's currently executing. Alternatively, somehow get a traceback of that thread. Is there any way to do that?
I tried creating an Android Studio project from the source tree with development/tools/idegen/idegen.sh, but I'm not sure how to proceed from there. In case it matters, the (legacy) device is running Android 6.
I've also just discovered debuggerd. I call logcat -s GpsLocationProvider to find the corresponding PID, and feed it to debuggerd, both with and without -b argument. However, this only gives be a backtrace into native code. I don't see any java code there.
If I'm not mistaken, if you have the respective Android API version in your AndroidStudio (installed through SDK Manager), you can install debug variant of your app on the device and then put breakpoints inside Android's code.
This way you can pause the execution of the component's code and see what it's doing.
I am debugging memory corruption issue and I want to check whether SF is accessing invalid memory or not but I don't know how to launch SF using command line. Please help.
SurfaceFlinger is started by the system fairly early on, and isn't usually launched by the user from the command line.
One approach would be to insert the valgrind command into the initd control script, modifying init.rc. This is harder than it sounds because of the way the rootdir is mounted.
Replacing the surfaceflinger binary with one that launches SurfaceFlinger running under valgrind should work; just make sure you wait() for it to finish or initd will assume it died when the launcher exits.
Of course, the best way to tell whether or not SurfaceFlinger is accessing invalid memory is to see if it crashes, though perhaps your definition of "invalid" extends beyond "unmapped or mapped incompatibly".
You'll get some complaints out of valgrind from various ioctl()s, particularly where the Hardware Composer is concerned.
I am currently compiling and executing some C++ code on a rooted Android device. I use adb (adb shell). To compile my code, I don't use the NDK, but I cross-compile with CMake
I'm using the function sleep(seconds) of unistd.h.
I've experienced some curious behaviors with that function on Android: Basically, I have a for loop in which I std::cout something and then call sleep(x).
If I call sleep(1), the behavior is the one expected: The program waits 1 second, and then executes the next instructions.
If I call sleep(2), the behavior isn't the one expected. The program gets stuck on that instruction for ever.... until I hit a key on my PC keyboard (not the device's one), and then it gets stuck on the next sleep(2)... until I hit a key, etc...
This behavior happens only when the device screen is off. As soon as I click on the power button to turn the screen on, the program resumes and has the expected behavior.
N.B: The behavior is the same with usleep(useconds)
I have tried to see where the limit is between 1 and 2 seconds:
1.5s, 1.25s, 1.125s -> always stay blocked | 1.0625s -> ~50% chance of staying blocked.
Obviously, there is something that prevents a thread to wake up if it sleeps more than 1 seconds (at least 2).
So my question would be, does anyone have any idea of why this is happening, and has a detailed explanation of the process ?
Thank you !
Android puts applications in the background when they aren't doing any user interaction - unix sleep and java timers etc. won't wake them up. You have to use an android alarm or runnable postDelayed handler.
My android native application crashes randomly but frequently, and I am unable to get sufficient info out ndk-gdb. This is the message following the crash:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 19983]
0x4012c6ac in memcpy () from /Users/Andreas/dev/android/obj/local/armeabi-v7a/libc.so
bt returns an unusable callstack:
#0 0x4012c6ac in memcpy () from /Users/Andreas/dev/android/obj/local/armeabi-v7a/libc.so
#1 0x67337388 in ?? ()
Cannot access memory at address 0x7
#2 0x67337388 in ?? ()
Cannot access memory at address 0x7
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
I am using NDK-r8e
I have checked all uses of memcpy() in my program and they're not responsible for this (verified by making them call another memcpy-like function with a different name, and still getting the above crash with the exact signature).
Any ideas how to get a more useable call stack, or to further debug this? Does the NDK offer any memory check functionality in case this is a memory overwrite?
Is it possible to trigger an GDB break from C++ in an Android NDK program which still allows the program to resume afterwards?
Meaning, I hit the assert causing GDB to halt the program, and I want to be able to press the "Play" button in Eclipse to resume the program, continuing beyond the assert.
Right now I am using:
__asm__ ("bkpt 0");
This triggers the program to halt, and brings me to the line of code that triggered it, but does not allow me to resume afterwards.
GDB output the following at the time that the program is halted.
(gdb)
82 info signal SIGBUS
&"info signal SIGBUS\n"
~"Signal Stop\tPrint\tPass to program\tDescription\n"
~"SIGBUS Yes\tYes\tYes\t\tBus error\n"
82^done
(gdb)
If I press "resume" at this point I get the following output in the LogCat:
Fatal signal 11 (SIGSEGV) at 0xfffffffd (code=1)
Perhaps my quesiton is how to throw a non-fatal break?
The standard Linux way of detecting if your process is being debugged is:
if (ptrace(PTRACE_TRACEME, 0, NULL, 0) == -1)
//Yes, we're running under GDB
With that in mind, do a conditional hard breakpoint (bkpt 0) that only fires when under debugger.
Not sure if Java-only debugging in Android would affect ptrace. Give it a try.
EDIT: call raise(SIGABRT) to break. Then in GDB, type signal 0 to continue. Other signals, like SIGINT and SIGTRAP, might work too.