I have been working on a project, and when I run the project in android studio it had been running correct and when I ran in debug mode it ran correctly.
All of a sudden, when I try to run the project normally, it pops up on the device waiting for debugger
and in the logcat I get this:
02-07 10:38:46.444 3968-3968/com.geog.test D/dalvikvm﹕ Late-enabling CheckJNI
02-07 10:38:46.784 3968-3968/com.geog.test W/ActivityThread﹕ Application com.geog.visitdub is waiting for the debugger on port 8100...
02-07 10:38:46.804 3968-3968/com.geog.test I/System.out﹕ Sending WAIT chunk
and it goes no further. I don't know why this is happening, there is no debug command in the manifest, I have killed the adb and restarted as I did with android studio.
It's a real pain in the a*** as I can't run the app without going through debug mode. If anyone has any ideas I'd like to hear them
Thanks
Restart your Android Device once and also check there should not be any breakpoints in your java classes.
The above suggestions were too invasive for me so I digged a little more into it. The following solution works for me in android studio:
Start debugging. (You'll get the wait chunk message here)
Select the Debug pane with the bug icon.
press the small cross at the side menu.
press "Force close" on your device.
Restart debugging.
In my case, there was an AsyncTask whose doInBackground() method called android.os.Debug.waitForDebugger(), and this was being picked up even in run mode. Disabling the line fixed it. Restarting the device didn't help.
try this , always work :
1 - close Android Studio and any other IDE you have opened (maybe you have Eclipse also running?) and emulator instances;
2 - remove USB cable from PC and restart your phone if you use one ;
3 - run adb kill-server from console;
4 - open Android Studio;
5 - click on run/debug;
6 - when the window to select the device appears, attach your device to USB and USB to your computer;
In my case it was a service to which I had added android.os.Debug.waitForDebugger(). The service was in a separate process by defining in the manifest android:process=":sepprocess"; after removing this line (such that the service is in the same process as the main activity), debugging started to work in the service and I did not experience the
I/System.out﹕ Sending WAIT chunk
anymore.
First clear all the break points from your project using ctrl+shift+F8 for windows or for mac cmd+shift+F8. Restart your android device. Then run
In my case, there are multiple debuggers. I have native code running in my app.
I cleared it by selecting the Debugger and Process from Run->Attach Debugger to Process
I deleted the emulator and recreated. It worked for me.
Related
When I debug a Cordova app what I constantly do is step through its code inside Chrome's WebInspector. In order to be able to do this, however, I have to wait for the device to become ready in chrome://inspect/#devices (only then can I click on the appearing link for the started app). But if I do this the inspector will not halt on breakpoints if I am not quick enough. How do experienced Cordova developer tackle this issue?
Additionally to frank's comment I just found GapDebug which offers instant debug and, thus, comes close to what I deserve.
I'm using xamarin studio and monotouch for developing iphone applications. When I set break points on my code and start debugging with the xamarin studio, the debugger breaks the codes on the break point correctly, but the problem is that when I trace the codes with debugger after some seconds ( maybe 30-40 sec) the debugger stops debugging, just like a crash. What should I do?
EDIT
I noticed that it is not because of the break point. Whenever I do not work with the phone after a few seconds the debugger disconnect and stop debugging. Is this really a bug? I think maybe there is a setting that if I change it then the issue will be fix.
Isn't this done by the iOS operating system??? doesn't it only give you ~30 seconds to return from the first event otherwise it kills the application process ? So if you sit in the debugger then it will kill that too?
If it's a bug, verify if there is a newer release and update you copy.
Otherwise, report it to the software providers for a solution.
I've associated my Windows 8 App with a file type. However when I open that file my app starts to open and then crashes.
I can't figure out a way to do this while the debugger is attached.
I assume there is something wrong with my OnFileActiavted method so I've resorted to changing random bits of code in that method. This isn't working, so I'm wondering how I should debug this problem.
Does this work? You can debug without launching the app immediately. You can also debug other people's apps.
Another approach:
Debugger.Launch();
When your app starts and execution reaches this line, your app will be stopped and VS will ask if you want to attach a debugger.
I have a simple Windows Phone 7 application which is working perfectly when started from Visual Studio. However, if I deactivate the app (press Windows button or back button from the application's MainPage) and then click the app's icon to relaunch, the screen will flash and return to the list/home screen. I assumed this was an issue with the emulator but when I got a developer device I have the same issue.
Note that reactivating without a complete tombstone works (pressing Windows button from the app and then back).
I have no idea what causes this or how to proceed with debugging. Hopefully someone else has experienced this and knows a fix.
Turns out there is a bug, i found the solution here http://forums.create.msdn.com/forums/p/67522/416995.aspx
In short, it turns out that the Microsoft.Xna.Framework.Media.MediaLibrary class (which I am using to display pictures on applications main page) is not properly initialized when the user has not opened a media hub prior to you calling it. So picture collection properties are null or empty. The solution is to add a call to MediaPlayer.Queue.ToString(), it will force the initialization of the native media library allowing you to invoke the MediaLibrary later on.
Sounds like an unhandled error on startup is causing the app to crash.
Trap/log/handle/display any unhandled exceptions. Also check what you're doing on startup.
IF you are saving something (to Isolated Storage) after first run and then opening it on subsequent launches then that's where I'd look first.
If it works when launched from Visual Studio then this will probably be due to the way you are rebuilding/redeploying the app before launching it in that case.
Is it possible to emulate a device sleeping and waking using the Microsoft-supplied device emulators?
Yes, but you have to generate your own emulator image with a modified kernel (changing OEMPowerOff). Bruce Eitman blogged about it here. You didn't detail your needs, so it's hard to say, but you might be able to provide some form of simulation by manually setting the named power management events.
This is an old thread, but in case anyone else stumbles across it, you can make the Windows Mobile emulators 'sleep' and wake up, though not with the debugger attached.
Close the emulator window while your application is running and save the state. Or, configure power management to sleep the emulator at the desired time; the emulator will close and save its state automatically. If the debugger is attached, it will lose its connection and stop debugging.
Open Device Emulator Manager and click Refresh until the emulator shows up as disconnected (no icon next to it). Right-click on the emulator name and select Connect.
Emulator wakes up and reappears. If your application is listening for the wake-up notification, it will be signaled at this point.
You can also wake up the emulator using Debug > Attach to Process, though this does not always succeed. Either way, by the time the debugger attaches, the wake up sequence will already have executed. If you can get by with debug statements, though, this is easier than modding the emulator image.