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.
Related
After the setup I've done in the properties of the project: at C++Compiler and Linker in both Release and Debug configurations I tried to build the project, which went successful.
Then I decided to run it and had some difficulties: using External Terminal, that did absolutely nothing, Standard output, that showed some text related to dll files I've clue about, Internal Terminal, that showed the very same text.
After that didn't work I went for cmd execution and what I saw was this.
Could you explain what that means and what I'm supposed to do. I'm new to all that kind of stuff, so I apologise if I did something stupid.
Cheers
EDIT: If not seen, I'm using Windows 10 and the version of SFML is GCC 7.3.0 MinGW (DW2) - 32-bit
I have OSX Yosemite 10.10.5, QtCreator 4.1.0, Qt 5.7.0 and Xcode 7.2.1.
If I write any native C++ program in QtCreator (console, gui - anything) I am unable to debug that program from QtCreator. Breakpoints get ignored, the program executes without pause and runs to completion no matter what I try.
I have tried the Xcode's LLDb, system GDB and Homebrew GDB as debuggers. the versions of GDB fail to start. Homebrew GDB has been codesigned.
This all used to (a few year back) just work beautifully and I am at a loss as to what might have changed.
Curiously, if I generate an exception inside the program - like accessing through a null pointer, the debugger shows me where this happens in just the way I would expect so, presumably, the debugger is running but simply treating me with complete disdain.
I know there are many versions of this question but none seem to address the problem adequately or offer workable solutions, or they apply to much older versions of the products.
Any suggestions?
This version of qtCreator (4.1.0) saw the return of the warning about having the build directory at the same level as the project directory. In Windows, this is done automatically. My mac installation does not get it right. (I may have messed a while back - cannot remember).
So - if the build directory is inside the project directory, debugging fails. Move the build directory up to the same level as the project directory and everything seems to work fine.
You can set the default build directory in the preferences/Build & Run dialogue. The path should start with ../
You will need to think about the folder structure before setting up the project unless you want build folders appearing in awkward places. So, a project folder structure like this is OK:
But one like this is not:
If this was already obvious to you, great. I have been messing with this for ages.
Many thanks to those who replied and anyone else who took the time to read the question. What helped e find it was the suggestion by #AlexanderVX that his setup was the same as mine but his worked. The only bit of my setup he could not see in the screenshots was the start of the build path. So that was the clue.
I am developing a C++ project with Xcode.
My Xcode keeps crashing out of nowhere. It does so often that it is nearly impossible to work at all. I have been using Xcode 6 until now. Since it kept crashing, I just thought I would format everything. I did a clean install of Yosemite and then downloaded Xcode 7 beta 2 from the official Apple Developer page. I installed it on my clean system, then pulled my repo and tried to work. Still the same problem.
Here is the log of the crash:
http://pastebin.com/t4gMWa95
I have looked around SO and many answers suggested that this could be related to source control. However, I tried to disable source control from my settings and still it crashes as often as before.
Anyone can give me an idea on what is going on? This is frustrating...!
Hmm the crash is in clang::DiagnosticRenderer::emitDiagnostic which presumably is redering errors and warnings. Could there be something odd about your warnings? Or something that is echoed in warnings classnames, scource file names, paths to source files? Does it happen when there is so little code as to have no or few diagnostics? But first - make a new XCode project and add your source to that, see if the new one works better.
Go to Users>[UserName]>Library>Preferences
Search for "xcode" inside the "Preferences" folder
Move all the resulting files (I had 6 files when I searched) to Desktop
Restart your Mac
Now open Xcode and see if its crashing
These steps solved my problem. Hope this helps...
I'm writing a C++ application using VS2010 on two dev computers - both are Win7 64bit SP1. I use git to sync the repositories.
On one of the machines the compiled executable (and also the test exec) stopped working with the following error, while on the other machine it works fine and I'm able to continue development.
The application was unable to start correctly (0xc000000d). Click OK to close the application.
I tried deleting the repository and cloning it again. I also made sure I have the same versions of Boost, git, Visual Studio. Also, I tried debugging (stepping in) but the error occurs before any line of code is reached.
Notice as far as I understand I'm tracking Visual Studio's solution\project configuration files as detailed here.
I'm at a loss, how would you debug this?
UPDATE 1:
Only the Debug version fails to run. The Release version runs fine
UPDATE 2: The executable that doesn't work does work on the other computer!
UPDATE 3: I've reinstalled VS2010 (exactly the same version) - didn't help. Surprisingly the compiled files are not the same size between the two machines.
I got the same problem as you mentioned.
My solution:
Clean the manifest file and rebuild
In the property page-> Manifest tool -> make sure "Additional Options" is set to nothing.
(I set it as "/validate_manifest" before).
Or you can try "Embed Manifest -> NO", rebuild and then set back to Yes. It sounds to be ridiculous, but it really works sometimes. I don't know why.
I got the same phenomenon suddenly without a warning on Win7 / VS2010 / C++. Debug App couldn't be launched, got 0xC000000D at initializing and loading multiple dlls. Found one base dll of my own responsible, played around with linker settings. Modifying settings, incremential rebuild -> app starts, rebuild all -> app crashes again. After setting "generate manifest" to "no" in the linker settings the sample app works, but the main app still crashes. After setting "generate manifest" to "no" for the most of my dlls -> the app starts in debug mode again. The stuff is very spurious, because some dlls need the modified settings others do not.
Have a look at the top two answers to this question
Program crashes with 0xC000000D and no exceptions - how do I debug it?
On the machine where it fails, try running the debug executable NOT under the debugger, and update your question to say what happens. If it crashes, are you able to then attach the debugger whilst the message box is still there and get a stack trace that tells you what function it is crashing in?
This is the weirdest thing....
Try deleting the "ipch" directory and then rebuilding.
Hope it works for you, I have wasted hours on this.
disabling/enabling precompiled headers fixed the issue for me.
I was facing crash on Debug x64 only - I guess it was related to an upgrade from boost 1.50 to 1.52, while keeping pch files.
in my case i got it working again by setting generate manifest to NO on all projects
I have changed "Embed manifest" setting to NO and then back to YES but it didn't help.
For me setting General->Platform Toolset to Windows SDK 7.1 for my program and all dependent libraries compiled with it helped.
It's the ipch just delete the entire folder and it will clear it up. I was confused for a while too.
I saw the error while using OpenCV library compiled with MSVC2010 in a project running on MSVC2015. Changing project configuration properties->General->Platform toolset from Visual Studio 2015(v140) to Visual studio 2010(v100) resolved the error.
I’m porting a C++ sdk from Windows to Mac OSX 10.5. I have a problem in Xcode where my breakpoints in certain files will only be hit if I set them while debugging. If I stop debugging and then restart, the breakpoints no longer get hit. If I add them while not debugging, they don't get hit. This is only in certain files and my breakpoints are always dark blue. i.e. I can’t tell the difference between a breakpoint that will get hit and one that won’t.
Specifically, my sdk is made up of various dynamic libraries. These are built using Perforce jam, which calls the various compile and link executables depending on my OS and compiler version (such as Visual Studio’s cl.exe and link.exe). I have a simple (unit testing) command line application that links to these dynamic libraries and calls code in them. This application on Windows is a Visual Studio project, in which I set breakpoints on library code and expect them to be hit.
I’ve created the same C++ command line utility application in Xcode 3.1.2 that links to the sdk dylibs and calls code in them. Some of the breakpoints work fine. I can set breakpoints in code that’s called from the troublesome code, and step out to the troublesome code, which I can then step through fine. The troublesome code is compiled into the same dylib as code that works fine. It’s also long and complicated enough not to be a candidate for inlining.
I’ve tried the following:
Turn Load symbols lazily off.
Compile with both gcc 4.0 and gcc 4.2.
Do a full clean and shutdown.
Delete the user-specific files of the xcodeproj package.
Rename the files so they can’t clash with system files.
Clear everything out of the Breakpoints window.
Create a new Xcode project.
My application is compiled in debug with DWARF format and my libraries are built with the –g flag (along with –v, –arch i386 and –fvisibility-inlines-hidden).
Help would be much appreciated. Thanks.
Update: sorry for not updating this, my Mac port project was postponed. I never resolved this, but discovered that it actually only occurs in constructor bodies. I'll revisit this as and when I hit the problem again.
Have you tried these?
Why aren't my breakpoints working?
Not really an answer: You should make a bug report in the official Apple bugtracker. The chances are high that you get an answer sooner or later there - or perhaps it is really a bug.