I am developing an app that crashes in NDK code with SIG_SEGV. This causes the app to hang for about 15 seconds, then Android will prompt me to force close it. This prints the java stack-trace to logcat, but I don't see any stack-trace for the NDK. I have redirected stdio with ADB but I still don't see a stack-trace. How can I print C++ stack trace to logcat or where is being printed too?
Using Android 2.3.4
NDK r8b
The "force close" dialog is posted by the crashing application. This sounds like a Dalvik crash rather than a native crash. If the process is receiving a SIGSEGV it should be notifying debuggerd and exiting, leaving a trace in the log. It might be helpful to include logcat output from the crash in your question.
At any rate, recent versions of Android include the native traces mixed in with the Dalvik stack dump when threads are in native code. If you have a rooted device running a recent version of Android, you can ask debuggerd to dump a trace of all threads with adb shell debuggerd -b <pid>.
You're on Android 2.3.x, though, so none of that helps you. Your best option is to send the process a fatal signal to get the debuggerd crash dump. The signal must be sent twice, e.g.:
adb shell kill -6 <pid> ; sleep 1 ; adb shell kill -6 <pid>
This requires a rooted device, as the "shell" user can't send signals to arbitrary processes. Depending on what exactly is going on, you should be able to do this while the "force close" dialog is still on screen... but if the thread managed to crash without taking the process down then there may not be a stack to get a trace from.
You can use the following code to get Log
__android_log_print(ANDROID_LOG_ERROR, "TRACKERS", "%s", Str);
and add the following library
#include <android/log.h>
There is a tool called CheckJNI and the tutorial to set it up is there.
Related
Background
I'm debugging an Android application using gdb 8.3 under WSL (Windows Subsystem for Linux). When debugging my app gdb frequently catches SIGSEGV and other signals that terminate the application, in general at inconsistent points in the session. These signals do not occur when the app is run without gdb. I have good reason to believe that gdb is the source of the instabilities.
I therefore want to monitor the running gdb-app using strace, in the hope of exercising the app and seeing what system function generates the offending signal when it crashes.
The Problem
strace is unable to attach to the gdb-debugged Android application because it cannot attach to an already attached process.
Here is the gdbserver command to attach to the running process:
dreamlte:/data/local/tmp # ./gdbserver :9999 --attach 26060
Attached; pid = 26060
Listening on port 9999
Remote debugging from host 127.0.0.1
I start gdb, which attaches to the running application.
With gdb attached to the Android application, I attempt to attach strace to the application:
127|dreamlte:/data/local/tmp # ./strace -p 26060
attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted
I understand the problem is that the application process cannot be attached to more than once.
Is there a way to attach strace to a running gdb-app combination?
I understand the problem is that the application process cannot be
attached to more than once.
Yes, this is the limitation of ptrace() system call, see ERRORS section in man ptrace:
EPERM The specified process cannot be traced. This could be because
the tracer has insufficient privileges (the required
capability is CAP_SYS_PTRACE); unprivileged processes cannot
trace processes that they cannot send signals to or those
running set-user-ID/set-group-ID programs, for obvious
reasons. Alternatively, the process may already be being
traced, or (on kernels before 2.6.26) be init(1) (PID 1).
I therefore want to monitor the running gdb-app using strace, in the
hope of exercising the app and seeing what system function generates
the offending signal when it crashes.
Instead, you can see backtrace when the app crashes. You will probably see some system function generating signal or something else you do not expect.
I made a Jenkins job to continually test Android Monkey.
My purpose is to find hidden errors of exceptions.
I ran it 420 times and cannot find any error.
Is there a way I can find errors or exceptions automatically and save log file?
ADB monkey generates crash log to STDERR.
However, sometimes, it goes to STDOUT.
So, if you check both STDERR and STDOUT, you can get crashlog and by checking the size of STDERR, you can identify if there was a crash or not.
On every runtime error in AIDE (when the application crashes) the logcat window is displaying all messages again (even from the last days) which needs long time to scroll to the end to find out what's wrong. I don't want always clear the logcat list before i compile the project, but i did not find any setting to avoid this behavior. Does anyone have a solution for this?
Actually you can have command line,use
Terminal IDE if your device is running on android 4.x
or lower,
Termux if Lollipop+,
launch your app within one of these Terminal Emulators with am command:
am start -a android.intent.action.Main -n com.your.package/.Ur_Main_Activity
And then use the logcat command to observe log, it will be a bit cumbersome though, use filters as you see fit. Enter ctrl+C to end Logcat dump. Hope this helps,
I am using an open Source Library for my Android Application. However its developers did not remove all the Log statements before releasing it. This causes a lot of ruckus in LogCat.
Is there a way to turn the Log Messages from a specific Java library Off ?
You can Filter LogCat outputs by some specific Tag names , like (adb shell)
adb logcat -s "TAGNAME"
My Android app, which I'm running on a Samsung Galaxy S4 and starting via Eclipse, occasionally crashes. Instead of dumping a stacktrace to LogCat it says that it dumps it to /data/anr/traces.txt. The problem is I don't have permission to read the anr directory so 'adb pull /data/anr/traces.txt' just gives a permission denied error.
I just want to read my stacktrace. Is there anyway to force it to dump to LogCat? Or at least dump it to a file I have permission to read?
Much thanks...
You should be able to dump the logs locally like this:
adb logcat -d > log.txt