Summary: debugger ignores breakpoints on Appceleration Titanium Studio IDE.
I'm using Appcelerator Studio, build: 4.10.0.201709271713, fresh install on macOS 10.14.1 (Mojave). My iOS project compiles and runs on the simulator just fine, everything behaves properly normally.
When I try and debug, however, execution ignores any breakpoints and just barrels on. I've checked all obvious settings, tried setting breakpoints every way possible, no luck.
If I launch the app under debug in the simulator and just let it sit there, eventually a dialog box will pop up saying "'iOS debugger on simulator...' has encountered a problem. Debugger failed to connect".
Anyone out there know what to do from here? I've been using Studio for years and the debugger part has always 'just worked'. I'm not sure where to look for port and connection settings.
Related
I haven't used CLion in a bit and something is amiss - when I try to debug, breakpoints are not hit. I see the checkmark flash briefly but the program continues to run. Here is a 15 second video showing what happens:
https://youtu.be/txn6W6aSWnM
This project is the vanilla Hello World project with a couple of lines of code added to the main program, and a breakpoint added in the middle.
This is a new Mac - is something misconfigured? Or has something broken in CLion?
Note: This is still happening with 2018.1. I've reported to JetBrains and sent various logs, etc., but still no ability to debug.
I'm using a Mac with the latest version of OSX (10.13.4 as of writing), and also using CLion 2018.1.2. I had this same issue.
The fix was straight forward. Simply go to Tools > CMake > Reset Cache and Reload Project.
ensure the Configuration is the same as the pictureenter image description here
Simply go to Tools > CMake > Reset Cache and Reload Project.
For anyone who ends up here, I was running Clion 2018.1.2 on MacOSX Catalina and had all kinds of problems (specifying GDB vs. LLDB, reseting cache, rebuilding project, etc... nothing worked). I upgraded to Clion 2020.2.1 and debugged the identical project I was having problems with and BAM; breakpoints, variables, stepping into, etc... all worked.
Hi I'm working on a c++ project by visual studio 2015 and windows 10 enterprise.
But I can't make windows to show close/debug window on crashes. I want to use jit debugging to find cause of crash for example I wrote this code to crash my program
// testvc2015.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include "assert.h"
int main()
{
char *b=0;
b[11] = 36;
assert(false);
return 0;
}
and when I run this program in windows 10 I got this dialogue
stop working
then I got this dialogue and program exit without any chance for debug
no debug button
I double checked the jit debugging in vs2015 and the options are set also I checked windows error reporting service and it's running.
How can I make windows to show debug button on crashes?
It was not the Windows Debugger button, it was the JIT debugging button. If we want to use it, we would enable the JIT debugging.
Troubleshooting steps:
(1) Just run your VS as the admin, and then enable the Just-In-Time Debugging in Visual Studio, run your app again (Ctrl+F5).
(2) I also suggest you reset your VS settings, and then test it again. At least, we could know that whether it was related to the VS settings.
I test it in my VS2015 with update 3, I could get the debug button.
If still no help, I suggest you repair your VS, view the result.
After trying all kind of crazy ideas I disabled the windows firewall and it fixed my problem! I enabled the firewall again and its working for now.
I am writing a small Linux app using Visual Studio 2015. To do so, I am using the Visual Studio 2015 Linux Extension, v 1.0.7 (the latest version as I'm writing this post).
I can compile and run the app on the remote environment using gdbserver, but I can't use breakpoints. I don't get why.
Details:
The target environment is a remote Ubuntu 64, on which g++, gdb and gdbserver have been upgraded today.
The extension works in that sense the C++ code is properly sent to the remote environment and properly compiled as a result of pressing F7:
My code (I am using some toy code for this post)
The resulting build log
The code is also properly executed remotely using gdbserver when I'm running it: the output is properly sent back by gdbserver as I can view it in VS's Linux Console Window.
My problem: when I set a breakpoint in my code (as in line 7 of my code above), it is just ignored. And when I just press F11 to start debugging straight at startup, the program just runs as if I wasn't debugging.
I'm wondering whether this is tied to the debugging from host 127.0.0.1 message above.
Of course I'm in debug mode when trying:
Optimizations are disabled:
Symbols are there:
And debug settings are by default. I left them unchanged after having installed the extension. There are no ports set, could it be the cause?
And finally, I can do some step-by step debugging if I replace gdbserver by gdb in my debug configuration above, and if I use F10 (or any other stepping option), not F5, to start debugging. The drawbacks being that I lose the Linux Console and I still can't set breakpoints, they are ignored. I have to step during the whole execution path:
This is the first time I am trying this Linux Extension with a remote environement. I was formerly using it with a local Cygwin and had no issues with breakpoints. But this was the previous version (1.05) of the Visual Studio 2015 Linux Extension so this does not prove anything.
Any idea?
I have a Universal Windows Platform app that was working fine. My development machine is running Windows 10, and after the Windows 10 November Update (1511, build 10586), the development version built by Visual Studio has stopped working. I was actually running this day-to-day as a standalone app, and I noticed this problem when after the update the app started immediately closing after the splash screen.
I uninstalled the development version of my app and installed the store version, and that works fine, even though no code has changed between the two versions. I updated Visual Studio to Update 1, and it still doesn't work. I've fully uninstalled and reinstalled Visual Studio but that didn't help either. I've also tried changing the Project Properties to target platform version 10.0.10586.0 and rebuilding, but that also doesn't seem to help.
This occurs on both Release and Debug builds, and on both x86 and x64.
On launch, it gets as far as the splash screen before informing me that I've triggered a breakpoint. The breakpoint was not set by me, but rather is in KernelBase.dll, and no source is available.
If I hit Continue, then I get an Unhandled exception at 0x00007FFC4C431F08 (KernelBase.dll). The body of the error is:
0x00000004: The system cannot open the file (parameters: 0xFFFFFFFF80004005, 0x0000000000000005).
Hitting Continue again will get me into my code, which dies with:
Microsoft C++ exception: Platform::COMException ^ at memory location 0x000000C1517FAF50. HRESULT:0x802B000A The text associated with this error code could not be found.
Any ideas on what happened and how to correct?
I left a program running last night, it worked fine for about 5 hours and then one of its built-in self-diagnostic tests detected a problem and brought up a dialog box telling me the issue. The program was built with debug information (/Zi). Is it possible to somehow get the debugger started so I can examine the value of some variables within the program? Or is it too late?
You can attach the debugger to the running process:
Debug > Attach to Process...
Just open up the program's solution first.
Assuming you've still got the error dialog on the screen you can break into the program and work back up the call stack examining variables etc.
For the future crashes ... if you have windbg or Visual Studio Professional, you can debug crash dumps, even when program isn't running. It is quite useful sometimes. See "MiniDumpWriteDump" on MSDN for more info.
Other than that it is "Attach to process".
Professional edition of Visual Studio have Just-in-Time debugger, that will kick in as soon as anything crashes, even if MSVC wasn't running. It will also locate source code (if debug info and source code are available) and open/create solution for you.
There is an option in the Debug menu to attach the debugger to a running process, IIRC.