Unidentified LLDB behavior in Android Studio 2.2 - android

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.

Related

Android Studio Debugger process finished with exit code 127

Recently upgraded to Android Studio 4.2.1
I can launch my app successfully but when I try to attach the debugger I get the error in the question title (see screenshot below).
The app just gets stuck on the "Waiting For Debugger" screen.
Everything worked as expected prior to upgrade.
This is the output from the debug log
$ adb shell am start -n "com.*.*/com.*.*.MainActivity" -a android.intent.action.MAIN -c android.intent.category.LAUNCHER -D
Waiting for application to come online: com.*.* | com.*.*.test
Waiting for application to come online: com.*.* | com.*.*.test
Connected to process 9869 on device 'amazon-kfmuwi-G0W0X8089256FRU1'.
Capturing and displaying logcat messages from application. This behavior can be disabled in the "Logcat output" section of the "Debugger" settings page.
W/ActivityThread: Application com.*.* is waiting for the debugger on port 8100...
I/System.out: Sending WAIT chunk
Connecting to com.*.*
Now Launching Native Debug Session
com.intellij.execution.ExecutionFinishedException: Execution finished
Process finished with exit code 0
In logcat I also see
2021-05-19 12:55:32.855 10394-10394/? E/azon.kindle.cm: Not starting debugger since process cannot load the jdwp agent.
I have tried:
Restarting Android device
Restarting development device
Invalidating and Restarting Android Studio
Reinstalling Android Studio
My system is running Pop!_OS 20.10
Debug error
I've solved that by installing 'libncurses5' and 'ia32-libs' packages
This is a known issue and is provided on the android developer's official page. Here is the link https://developer.android.com/studio/known-issues?hl=de#native_debugger_crashes_with_debugger_process_finished_with_exit_code_127
It turns out it's a Linux-specific issue and is because Linux uses upgraded 'libncurses6' and android studio uses 'libncurses5' required to run the debugger.
I've solved this by installing 'libncurses5' only
sudo apt install libncurses5
Thanks to Max Elkin
I eventually solved this by rolling back to Android Studio 4.1.
I rolled back AS from 4.2 to 4.1.3 which solved the error
In case the accepted answer doesn't help, here's how to find the root cause:
Search for the Debug log settings action (via CTRL + SHIFT + A)
Set #com.jetbrains.cidr.execution.debugger:trace in the dialog (source)
Try run or attach the debbuger
Search for the Collect Logs and Diagnostic Data action (via CTRL + SHIFT + A)
Inspect the idea.log file inside the zip. It should show why the debugger fails.
For example, I saw this error brains.cidr.execution.debugger - LLDBFrontend: Fatal Python error: config_get_locale_encoding: failed to get the locale encoding: nl_langinfo(CODESET) failed
Which was fixed by setting this in ~/.zshrc (source)
export LC_ALL="en_US.UTF-8"
export LC_CTYPE="en_US.UTF-8"

Can strace debug an application being debugged by gdb?

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.

Android Instant Apps: How to debug an instant app?

When I debug my instant app on Android Studio, the debugger attaches to instant app process and pauses execution at most breakpoints. However it seems to ignore breakpoints at my main activity's onCreate method. I've tried "Debug" and "Attach Debugger to Android Process" options. What am I missing?
Basic information about how to use Android Studio debugger to debug an Android app is available at Developer Documentation Debug Your App
.
Android Studio debugger works normally most of the time when debugging an instant app. However, you will notice that the debugger will fail to stop at breakpoints early in the app's lifecycle (such as Application.onCreate or Activity.onCreate) on devices running Android N and below.
When your instant app is up and running, it runs under your app's package name. However, there is a short period of time during app startup when it runs under a temporary package name, in the following form:
com.google.android.instantapps.supervisor.isolated[0-9]+
This temporary name is assigned by the runtime. Because Android Studio is not aware of this name, the debugger will not attach to this process.
The workaround is to find out this temporary name and use adb to set the app to debug. This can be done by running the following command in terminal before running your app. It will print out the name when your app starts.
=> adb shell 'while true; do ps | grep com.google.android.instantapps.supervisor.isolated; sleep 1; done'
u0_i6 31908 630 1121664 29888 0 00ea57eed4 R com.google.android.instantapps.supervisor.isolated15
Once you identify the package name, use the following command which will pause and make your instant app process to wait for the debugger. Then attach the debugger normally, but choosing the temporary process name in the Choose Process window by clicking on “Show all processes”.
=> adb shell am set-debug-app -w --persistent com.google.android.instantapps.supervisor.isolated15
I had also problems recently debugging instant apps.
with multiple log messages
"Waiting for application to start debug server"
in the debug window and after several retrials
"Could not connect to remote process. Aborting debug session."
The way I solved the issue is
by using the "Attach To Process" option from Android studio "Run" menu.

Android VM crashes on Launch Mac

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.

OSX: Android Emulator Crashes

I've just reinstalled eclipse indigo (32bit) and the latest Android SDK. The Android Emulator crashes immediately after it is launched.
Here are my steps:
Create a new Adroid project. Target is Android 4.0, SDK 14.
Press the Run button in Eclipse.
See the Emulator launch and crash about 2 seconds later
Output of crash window:
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
The Eclipse console complains about the following:
Warning once: This application, or a library it uses, is using NSQuickDrawView,
which has been deprecated. Apps should cease use of QuickDraw and move to Quartz.
goldfish_fb_load: framebuffer dimensions mismatch
savevm: unable to load section goldfish_fb
emulator-5554 disconnected!
Cancelling 'com.sparky1.HelloAnrdroidActivity activity launch'!
Any thoughts about how to get emulator to behave?
This has already been reported as a Bug: http://code.google.com/p/android/issues/detail?id=724
There are some workarounds presented in this post, too. But at this point, there seams to be no actual fix.
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've seen this problem too. I've found that running emulator from command line and disabling snapshots help a lot.
I'm running:
$ emulator -no-snapshot-load #avd
If disable snapshot when create device, ok. Do not enable snapshot.
If enable snapshot, it's ok to check "save to snapshot" when launch device.
But check "launch from snapshot" is not ok. If already save snapshot, it will cause emulator-arm crash.
After emulator-arm crash by "launch from snapshot", disable snapshot with AVD manager does not work. But run config > target > additional command line option(-no-snapshot-load) works.
I had all these crashes as well and found this in my crash logs:
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 com.apple.CoreFoundation 0x97585bc1 CFStringGetLength + 17
1 com.apple.CoreFoundation 0x9759df63 CFStringCompareWithOptionsAndLocale + 35
2 com.apple.CoreFoundation 0x9759df2c CFStringCompare + 60
3 com.b-l-a-c-k-o-p.CamCamX5 0x03ff3b44 CoreBundleyes::IsMainMember() const + 48
4 com.b-l-a-c-k-o-p.CamCamX5 0x03ff11cc QVDigBaseClass::ClassFactory(ComponentInstanceRecord*) + 50
5 com.b-l-a-c-k-o-p.CamCamX5 0x03ff317b QVDIG_DATA_Open + 23
After spending only a couple of hours :-( on the net I found a tip to remove
/Library/Quicktime/CamCamX5.component
After that no more crashes :-)
An alternative is to switch to using AndroVM in Virtual Box which is an X86 Android image. The big advantage is that it is lightning fast compared to the ARM one. It boots in 2-3 secs. The downside is that you have to manually do the ADB connection and the capturing of the mouse by virtual box is a pain. Not all applications will run on the x86 as well.
To use it you have to configure the first Ethernet adapter as Host Only, run the androVM configuration utility to get the emulator's IP address, then use adb connect ip-address
Another tip is that if the screen times out you need to hit F1 to wake it up.

Categories

Resources