I am trying to debug some OpenGL code, so I wanted to make use of the GPU debugger from Android Studio. For this I need to get a GPU trace, according to the steps detailed at https://developer.android.com/studio/debug/am-gpu-debugger-trace.html. But, after the dialog for trace name, Android Studio shows directly the message: Failed to attach to process.
Android Studio has version 2.3, and was recently updated.
On the device (Samsung S3) I see the alert: !Waiting for debugger.. process zzz is waiting for debugger to attach.
I tried to enable all GPU related options from developer options in device settings, also to disable all, with the same result. Is this feature working? My setup is not very uncommon.
I reached to a point where I get the message: The GPU debugger does not currently support tracing on this device. So the answer would be that it does not work on S3. I'll leave the question here, maybe it will save someone a few hours of investigation.
When trying to enable Run/Debug Configurations>Profiling>Capture GPU Commands, I was required to install "GPU Tools". Then, after accepting to install, it complained that they were already installed in the folder, and I should remove them prior to new installation. So I moved them away. Then it would give the error from the question.
After some attempts, I decided to put the contents of the folder back, deselect/select again Capture GPU. It said once again that I needed to install GPU tools, but this time I did nothing. The checkbox got checked anyway, and when trying to start the trace, went on to do some stuff without complaining about the attaching to the process. Finally it did not work anyway, but at least I know the reason.
Related
Since I upgraded my Android Studio installation to Bumblebee, the emulator has become unusable. It either crashes during startup or gets itself stuck so that the UI is unresponsive and the debugger either cannot install or cannot launch an app. The way in which it fails varies from time to time for no reason that I can understand. although different virtual devices seem to behave differently. I tried deleting my old virtual devices and creating new ones, but that didn't help.
I can't debug my code on a real phone because of a different problem, see my recent answer to Source code does not match the bytecode for Android's View.java.
When it crashes I send a crash report to Google, but they don't seem to be fixing it. The problems started with the first official Bumblebee release 2021.1.1, which seemed to have a complete new version of the emulator, and I'm now on the latest stable version 2021.1.1 Patch 2.
My environment is a Dell Precision M4800 with 16GB of RAM and an 8-core Intel processor, using an external 4K monitor and an external full-size keyboard, running Linux openSUSE Leap 15.3 with all recommended patches installed.
Does anyone have any suggestion short of throwing away my entire Android Studio installation and reverting back to Arctic Fox? Has anyone else seen similar problems?
Tintin's answer didn't work for me: Device Frame wasn't enabled anyway because I had noticed that it had caused problems before.
However the following sequence rather surprisingly, at least to me, did fix the problem.
First make sure that the toolbar is visible at the top of the emulator window: if it isn't, click on the gear settings icon at the top right of the emulator window and enable Show Toolbar.
Start up an emulated virtual device, and before it crashes click on the three dots at the right hand end of the toolbar: this will bring up the extended controls window.
Choose Settings from the list at the left of the extended controls list.
Set the OpenGL ES renderer to Desktop native OpenGL, and the OpenGL ES API to Compatibility (OpenGL ES 1.1/2.0).
Close the extended controls window and then close the Android Emulator window.
Check if there are any zombie emulator or qemu processes still running. If there are, kill them: you'll need kill -9 on Linux.
Try to cold boot an emulated virtual device: it will probably crash before it even gets started up properly.
Close the Android Emulator window and repeat step 6
Try to cold boot an emulated virtual device again, but click on the three dots quickly before it crashes.
When the extended controls list comes up, choose Settings from the list at the left.
Set the OpenGL ES renderer back to SwiftShader, and the OpenGL ES API back to Renderer maximum (up to OpenGL ES 3.1).
Repeat steps 5 and 6.
Now try to boot up an emulated virtual device again. It should work: at least it does for me.
If it doesn't work on your configuration, try all possible combinations of the OpenGL ES settings: you may find one that works.
Logically, changing the OpenGL ES settings and then changing them back again shouldn't do anything, but it does. My guess is that perhaps some needed bit of initialisation for the OpenGL isn't being done by the installer, but it gets done when you change the configuration.
I also faced this problem in both updates in 2021.1.1 it was not working at all. Updated to patch 2 again faced problems turned off Enabled Device Frame it is working OK now
I was trying to install SDK and Emulator without the Andriod studio on Ubuntu 20.04.
But got stuck at this error.
E0520 11:06:29.866803544 5261 socket_utils_common_posix.cc:201] check for SO_REUSEPORT: {"created":"#1589952989.866791260","description":"SO_REUSEPORT unavailable on compiling system","file":"/mnt/tmpfs/src/android/emu-master-dev/external/grpc/src/core/lib/iomgr/socket_utils_common_posix.cc","file_line":169}
checkValid: hw configs not eq
I got the solution from this article:
So in order to fix this, I just disabled the Camera by switching the option from Emulated to None and that was all.
Don't ask why this works, but it seemed to solve it for me.
Install Android SDK Platform tools. if already exist uninstall and install Android SDK Platform tool in ubuntu 20.04
Seems a GPU issue, try :
sudo ubuntu-drivers autoinstall
Or (or both) change graphic emulated performance to software if your emulated device allow it.
Had same issue with linux mint android studio ..
Hope it will help.
Though not directly affected by the error you described, when stuck at this point (namely, when supposed to be connecting back to the ADB server, but can't), this can be a result of a corrupted quick-boot snapshot.
What worked for me is to hard-delete the existing quick-boot snapshot, and have the emulator regenerate it on the next run.
To delete the snapshots:
rm -fr ~/.android/avd/<AVD name>/snapshots/default_boot
To regenerate the next snapshot, rerun the emulator as you normally would, then kill it after if full loads. But first, make sure that it is configured for saving a quick-boot snapshot on exit:
Edit quickbootChoice.ini, for example:
vi ~/.android/avd/<AVD name>/quickbootChoice.ini
The only line there should be:
saveOnExit = true
If you wish to see whether any of this is likely to help you before making any changes, run the emulator with the -no-snapshot argument applied, beforehand. For example:
$ANDROID_SDK_ROOT/emulator/emulator -no-snapshot #Pixel_API_29 &
(Or find a way to do this through Android Studio)
A note regarding other answers here that advised configuring the camera differently (which seems unrelated): It is very likely that changing the camera setting, for the Emulator, is considered a configuration change - which ends up in forcing a cold-boot (i.e. skipping usage of the quick-boot snapshot), which can explain why it works (but with no voodoo involved).
I've just downloaded Eclipse on elementary OS and attempted to launch it. After doing so, I saw the loading screen for a few seconds before it disappeared and left me with the desktop. Since then, my computer (an old Dell with 4GB of RAM and an Intel Core Duo) has been very unresponsive and the disk activity indicator is almost constantly lit up. I've been looking at the desktop for around 30 minutes now! How can I solve this problem and launch Eclipse?
EDIT: Running eclipse -clean from the command line produces the following error: The org.eclipse.m2e.logback.configuration bundle was activated before the state location was initialized. Will retry after the state location is initialized.
First, you might review your installation steps. If nothing is obviously wrong, check the following:
check for any error logs
check that you're using the proper Java version
make sure that there's enough memory allocated for Eclipse (see the eclipse.ini file)
as a last resort, try reinstalling it
See also the following guide for installing on Elementary OS: how to install
If that's not working submit more details of your specific problems.
NOTE: You may have to find the right Java and install it "by hand" rather than relying upon the distribution's package manager. You can "point" Eclipse at the right Java by editing the .ini file.
Some related links are as follows:
a similar symptom related to multiple screens and/or corrupt workspace
General trouble-shooting related to your issue and symptoms
I have a Kernel mode filter driver project. Host: Win8 Pro x64 running VS2012, Target:Win8 Pro x64 VM on the same machine. I was able to provision the VM through VS 2012 over the network. I deployed the package project. When I try to deploy and Install the package from VS, I am not able to succeed. So I manually installed the driver and the driver works fine. After installing the driver manually, I attach to the kernel of the VM and click on Break all. I find the Kd console in the immediate window of VS '12. I type the command "bu !DriverEntry" and then I type the "g" command. I see the message Debuggee is running. When I place break points on my code and press any key in the VM, I don't see the break points getting hit in my code. Need help!!
Use Fltmc command to load and attach your filter to a specific drive
You can put breakpoints directly in VS without the need to type in the console, if your filter is getting loaded after you type fltmc load "filter name" VS should stop at the driver entry function breakpoint, you may also need to attach it.
Dont forget to check if your debugger is working by when you click break all target machine should freeze.
I wasn't able to debug through VS. I went for a work around and this time I used a Win7 VM. Made use of the KdPrint() method and used the DebugView tool to see the messages. This is a lengthy process but atleast I'm able to debug my driver. Hope this helps someone else too
I followed the instructions in this link: http://msdn.microsoft.com/en-us/library/bt727f1t.aspx to install the remote debugger (2012) on my server where the application is running in hope to debug it remotely from my dev machine running visual studio 2012.
I cannot even get as far as viewing the list of processes to attach to on the remote machine. I keep getting "Unable to connect to the Microsoft Visual Studio Remote Debugging Monitor named [name]. Invalid access to memory location".
I have managed to successfully connect a few times but then the attach fails immediately then I cannot connect again.
This is causing huge issues for me as I cannot remote debug anything. I must be missing something glaring. Please someone give me a solution.
I've found the only way to correct this is by restarting Visual Studio.
Worked for me. I found it at this blog post about invalid access and remote debugging.
It turns out the one thing I missed was to tell Visual Studio where to find the .pdb symbols relating to the remote process. To do this go to Tools -> Options -> Debugging then in the Symbol (.pdb) locations add the remote location to the pdb files.
To clarify, I was attaching fine but could not break into code. Now I can. Be aware though that there are other hurdles before you get to my stage where I was attaching to the process successfully but could not catch a breakpoint.
I recently had someone else report this and debugged the issue on their machine. The "Invalid access to memory location" errors are due to an issue in Windows, it can be addressed with this hotfix.
I have had this problem in VS 2012, 2013, 2015 and 2017. Based on other answers it is likely that the problem is related to running a 32 bit version of Visual Studio on a 64 bit PC. Sometimes, as others have recommended, restarting Visual Studio fixes the problem but the best solution I've found so far is to start Visual Studio without a solution, open Debug -> Attach to Process, change the Connection Target to the remove server and wait for the process list to load. Then Cancel, do not attach yet. Load your desired solution and then come back to Attach to Process and the remote process list will still be loaded. Connect to your desired process and everything should work properly from then on.