I have to debug libmedia.so on Android 5.1 (LG G4) with kernel 3.10. I use IDA Pro 6.8. After I'm attached to the mediaserver process, in the segment view, IDA shows the code segment of libmedia.so with exact starting and ending addresses (controlled in /proc/pid/maps) but the routine's addresses of libmedia.so are outside the code segment of the libmedia.so. Ignoring that and going on with debugging, I set a breakpoint at the startInput routine, called when the microphone is needed. After setting the breakpoint, IDA returns:
F75EC260: got SIGSTOP signal (Stop unblockable) (exc.code 13, tid 8552)
The address 0xF75EC260 is in the libc.so and corresponds to instruction:
svc 0
Has anyone encountered this problem? Is there any anti-debug protection in Android 5.1? In previous versions of Android, there are no problems with debugging.
Related
My app runs fine but gdb fails to debug it with the following error
(gdb) target remote 127.0.0.1:8888
`target:/system/bin/app_process32' has disappeared; keeping its symbols.
Remote debugging using 127.0.0.1:8888
Remote target doesn't support qGetTIBAddr packet
I am on Windows 10 64 bit and using nox 32bit emulator.
The following message is displayed when gdbserver is started.
beyond1q:/system/bin # gdbserver :8888 --attach 3805
warning: Found custom handler for signal 39 (Unknown signal 39) preinstalled.
Some signal dispositions inherited from the environment (SIG_DFL/SIG_IGN)
won't be propagated to spawned programs.
what is the solution?
After the debugger reaches the breakpoint, the app process stops and after a little time (2-3 seconds) the debugger disconnect itself. But only if i debug with my Huawei phone (EMUI 10).
These are the last 3 lines from the log:
D/: [ZeroHung]zrhung_send_event: wp = 257, ret = 0
D/:[ZeroHung]zrhung_send_event: wp = 258, ret = 0
Disconnected from the target VM, address: 'localhost:8629', transport: 'socket'
If I debug the same app with the same breakpoint on an emulator, everything works fine. The debugger stops at the breakpoint, and doesn´t disconnect itself.
How did you build this project? If you build it with ant or other tools, make sure to compile with debugging information enabled (debug = true for ant javac tasks). Obfuscation and bytecode detection during construction can also affect the possibility of debugging. If you run it in some non-standard JVM, it can also cause such problems
When performing remote debugging, make sure to start the target process using the correct JVM options recommended in the IntelliJ idea remote debugging configuration. Your wrapper configuration may pass them incorrectly
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.
So I just updated to Android Studio 2.2 and I'm having problems running my app on my device. What seems to happen is that now there are two separate debuggers running when I try to debug my app. One of them is the good old Java debugger and the other one is I think the LLDB debugger.
My app has a splash screen which is presented as the first Activity in the app. What happened before was the splash screen would only be shown around 1 second before the actual intro screen showed up. After I updated my Android Studio to version 2.2, it takes around a minute before the splash screen disappears.
I put a breakpoint to the SplashScreenActivity.onCreate() to see if everything was OK. After I launch the app, it waits for some time before the LLDB debugger stops with a SIGURG signal. I click resume program and again it hits the same signal. This happens 7-8 times, after which my breakpoint in SplashScreenActivity.onCreate() is hit by the Java debugger. After this, the app keeps working normal.
I don't know if it helps but the console of the LLDB debugger is like this:
09/26 00:19:32: Launching app
No apk changes detected since last installation, skipping installation of D:\Documents\SourceTree\autocolorsplash-android\app\build\outputs\apk\app-debug.apk
$ adb shell am force-stop com.kayimapps.autocolorsplash_android
$ adb shell am start -n "com.kayimapps.autocolorsplash_android/com.kayimapps.autocolorsplash_android.activities.SplashScreenActivity" -a android.intent.action.MAIN -c android.intent.category.LAUNCHER -D
Waiting for application to come online: com.kayimapps.autocolorsplash_android | com.kayimapps.autocolorsplash_android.test
Waiting for application to come online: com.kayimapps.autocolorsplash_android | com.kayimapps.autocolorsplash_android.test
Connecting to com.kayimapps.autocolorsplash_android
Now Launching Native Debug Session
Starting LLDB server: /data/data/com.kayimapps.autocolorsplash_android/lldb/bin/start_lldb_server.sh /data/data/com.kayimapps.autocolorsplash_android/lldb unix-abstract /data/data/com.kayimapps.autocolorsplash_android/lldb/tmp platform-1474838375380.sock "lldb process:gdb-remote packets"
Debugger attached to process 927
Signal: SIGURG (signal SIGURG)
Signal: SIGURG (signal SIGURG)
Signal: SIGURG (signal SIGURG)
Signal: SIGURG (signal SIGURG)
Signal: SIGURG (signal SIGURG)
Signal: SIGURG (signal SIGURG)
Signal: SIGURG (signal SIGURG)
Signal: SIGURG (signal SIGURG)
I'm not using any C++ in my app other than some compiled OpenCV code, which I haven't touched at all. I'm only using the Java wrapper for OpenCV.
The debugger frame looks like this after the first SIGURG signal:
I don't know if there's any other relevant information I can give about the situation since I have no idea what's going on. Please do tell me if this seems like something you have seen before and requires some additional info.
So I couldn't find why LLDB made me wait for around a minute but I found where to disable LLDB altogether. I don't know if it was there prior to Android Studio 2.2, but you can go to Run->Edit Configurations and from the Debugger pane you can set Debug Type to Java instead of Auto.
This disables LLDB and turns things back to how they were before 2.2. However launching the app for the first time through adb still causes the splash screen to stick around for some time.
I have a problem.
I've been working with Android in Eclipse for the past 4-5 weeks now and never had a problem with the VM (they were slow, yes. But never crashed).
Now, I believe since 4.2 when I started working on a new project for uni (deadline next week) my 4.2 VM suddently starts crashing on launch, because of "Kernel Panic" (resport at the end).
I wanted to ask if there is anything I could do, maybe download a hotfix or anything. Both the API and Eclipse are pretty much up to date or might there be something wrong with my computer?
(Somehow even my old VMs (2.3.3, 3.1 and 4.1) crash on launch 99% of the time)
Any advice would be highly appreciated. Here the beginning of the Crash-Log:
Process: emulator64-arm [1334] Path:
/Users/USER/*/emulator64-arm Identifier: emulator64-arm Version:
??? Code Type: X86-64 (Native) Parent Process: eclipse [1156]
User ID: 501
Date/Time: 2012-12-01 00:25:27.469 +0100 OS Version: Mac OS
X 10.8.2 (12C2034) Report Version: 10
Interval Since Last Report: 130686 sec Crashes Since Last
Report: 96 Per-App Crashes Since Last Report: 32 Anonymous
UUID: ABE51F99-F7A9-2595-016E-C47FFD1F6C50
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes:
KERN_INVALID_ADDRESS at 0x0000000000000000
VM Regions Near 0:
-->
__TEXT 0000000100000000-0000000100247000 [ 2332K] r-x/rwx SM=COW /Users/USER/*
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
Do you have two screens? if yes, did you launch avd/vm on secondary screen last time?
If yes, then check config vm file at:
cd ~/.android/avd/
ls -la => here you see all avds
cd [your_vm.avd]
joe emulator-user.ini => edit this config file and see value
window.x = 2054 - this is stupid value, cause says where to display emulator window. Value is set cause emulator window was displayed at second screen on x position 2054 but as I say it's bug at avd. Simply change it to better value to display window at your main screen so like my case:
window.x = 954
window.y = 199
uuid = 1342941165631
Save config file, start eclipse, start your avd/vm and all must run well.
It looks like this happens when an external monitor is connected. Try disconnecting your external monitor and then start emulator. You can attach it back after the emulator starts.
I had the same problem. Yesterday it worked fine. Today crashes with EXC_BAD_ACCESS. Then I noticed that the audio I was listening to stopped for half a second when launching the AVD. I though that might have something to do with it. I stopped iTunes I was listening to, restarted the AVD and yes success. No crash, it started up nicely.