Running the latest stable version of Eclipse CDT on an up-to-date Windows 10 x64. I started off with the Eclipse IDE for Java Developers and then installed CDT plugin minus preview/beta/experimental features - it is my only plugin; I'm able to debug Java projects just fine, but when it comes to using gdb in C it does not stop on breakpoints at all; the debugger works perfectly fine otherwise. I can step through program, examine variables, see assembly output. I can even see the breakpoints correlating to the assembly.
I've gone through several posts on StackOverflow and various forums and none of them have helped me. In light of their suggestions, here is my current situation:
I do NOT have the "Skip All Breakpoints" button accidentally enabled. (I've also toggled it on-off during program execution, does not help.)
I AM in the Debug perspective
Running Eclipse as Administrator does NOT fix the problem
Disabling "stop on startup" does NOT fix the problem
I am using the default debug configuration, so there is no optimization and maximum debugging information (currently using -O0 -g3 flags)
Passing the -ggdb3 flag does not help
I've tried various combinations of cleaning/rebuilding project/clearing breakpoints/restarting Eclipse
I've tried creating new projects and copying and creating new source files and copying and pasting the contents of the original sources into the new ones - new project does not fix anything
The breakpoints I am testing are in guaranteed-to-hit-places in main (eg. a simple "Hello World" program with only multiple printf statements), so there is no issue regarding loading libraries or other source files
Run -> Breakpoint Types is currently set to C/C++ Breakpoints
I hope someone is able to assist!
as I said in the title, my application simply works fine in debug mode, but when I extract a release mode apk it just crashes on startup.
I have tried every possible fix I could found on google and none worked, that's what I tried so far:-
Setting linking to None / SDK Assemblies Only.
Setting code shrinker to None / ProGaurd.
Enabling support architectures armeabi-v7a and arm64-v8a.
Adding Internet permission.
Cleaning the whole solution and rebuilding everything.
Setting projects assemblies (PCL & Android & IOS) to lowercase names fails the archiving.
Enabling the Use Shared Runtime fails the archiving.
Enabling the Bundle assemblies into native code.
Uninstalling the Mono Shared Runtime from the device.
I also cleaned the solution and did a rebuild after each of these tries...
Nothing worked...
What am I missing here ?!
Thanks in advance ^_^
As #MohamedAshraf mentioned, when he tried to build it on an emulator in the release configuration, the app still crashed.
So, he was able to enable debug symbols and debugging in the release configurations as well, and was able to catch the exception and fix the issue.
Don't forget to turn debugging off in the release config again afterwards.
I'm trying to debug an executable which has been created with CMake configuration
SET(CMAKE_BUILD_TYPE Debug)
However, CLion does not hit any breakpoints. What could be the problem?
I had the same issue today. I figured out that the configuration for the project was not set to Debug. After setting the configuration to Debug all the breakpoints are hit.
Please ensure that you have following configuration:
Select the MenuItem Run/EditConfigurations
Select the right Target
Select Debug as Configuration
Now the breakpoints should be hit.
In case this helps someone else, it turned out that my (somewhat embarrassing) issue was that I was hitting Run instead of Debug. So in the Run menu don't use the play icon, instead choose the cute bug icon instead. Choosing Run was causing it to automatically build the non-debug build so breakpoints wouldn't work. Once I started choosing the bug icon, the breakpoints worked like a charm.
As it has turned out, the executable was compiled with following CMake options (further down in the script):
SET(CMAKE_C_FLAGS_DEBUG "-D_DEBUG")
This was breaking debug functionality for CLion (it was also breaking most of the debug functionality of gdb)
I also had the same Problem. Since 2016.3 CLion changed the CMake workflow so that only one configuration is allowed at one time clion new workflow
The solution is File -> Settings -> Build, Excution, Deployment -> change the build configuration
In my case my CMake option CMAKE_BUILD_TYPE was already set to DEBUG on CMake Settings. However, it was the command set(CMAKE_BUILD_TYPE Release) in the CMakeLists.txt, which was merged by git pull and overrode the CMake Settings while execution. I could not figure out earlier as CMake Debug console was showing -DCMAKE_BUILD_TYPE=Debug
When I changed it to set(CMAKE_BUILD_TYPE Debug) breakpoints were hit again.
In case this helps someone else:
In my case I had to set the -DCMAKE_BUILD_TYPE option to Debug explicitly in Settings -> Build, Execution, Deployment -> CMake
I had a different issue that caused my breakpoints not to be hit. I develop both embedded apps and native MacOS console apps with CLion. For the embedded work, GDB needs to be set for your selected Preferences/Toolchains.
For debugging console apps LLDB needs to be selected in Preferences/Toolchains. If it is left on GDB, my breakpoints don't work. Set to LLDB here:
I had a comma in my project path. Removing the comma fixed the problem for me.
In 2019.3, it turns out to be CLion/Preference/Build,Execution,Deployment/CMake/Build type/Debug.
My problem was with the -ffile-prefix-map flag. Once I removed it, everything worked fine.
See https://youtrack.jetbrains.com/issue/CPP-23159 and https://youtrack.jetbrains.com/issue/CPP-15850
I had the same issue. I noticed that every time I click the debug option, the "Antimalware Service Executable" process starts. I created an exclusion for MinGW folder in windows Defender and it worked fine...
Just like minecrawler said in github, if your os is linux, your should set：
file/Settings/Build,Execution,Deployment/Tllochains/Debugger from Bundled GEB or gdb to Bundled LLDB.
I tried and it worded！
In my case (Linux / Ubuntu) the problem was somehow related to mounted directory.
The project was initially opened in CLion from /media/username/ssd/repo/git/projectname. The breakpoints were always disabled with message No executable code is associated with this line.
Then I opened the same project from a symlinked directory
~/git -> /media/username/ssd/repo/git and the breakpoints began to work fine.
In my case I had to edit the file so that everything was compiled again instead of using cache.
In my case, the problem is forget to comment out optimize option add_definitions(-O3) in cmakelists. which let compiler go release.
in the case of "the platform is currently not connected" of CLION for RUST, it turns out there is an authorization step which is not enabled on CLION 2022.2 version.
download the correct version solves the problem
My UWP apps were running flawlessly on debug but instant crash on release, I've uploaded the package to app store twice and they tell me that my app doesn't work too. Unticking that .NET Native stuff helps but I'm not sure it will work on other users' pc and I have no idea what that does, I think something goes wrong.
My other projects can run Release build flawlessly, I've tried clean up everything and re-build but I get the same error.
Thank you
edit: tried running on my laptop, stuck at splashscreen then got the same error, I even tried removing anything on MainPage constructor and OnNavigatedTo.
Running flawlessly on debug but instant crash on release:
Unticking this helps:
I found the solution, I think this is a bug where Visual Studio passes command line to compiler which I suspect they forgot to put quote "" to cover the path.
Project with spaces in path
Project without spaces in path
Be aware that spaces must not exist neither in the path to the project file nor in the Assembly name.
Your app should be able to run on .NET Native because it will be compiled that way in the store (before users are able to install it).
Release builds do have code optimizations enabled, which will make it harder to debug. If you want to debug .NET Native, you should disable the optimizations.
For the full guide on debugging .NET Native, check the msdn article. I hope this helps in hunting down the actual problem (which can be plenty).
I am porting an iOS project to Android. I need to step through the methods in the Objective C classes to understand how they work and also to help with writing unit tests which will validate my ports. AppCode is my chosen weapon.
The problem is that whilst debugging, I often get "value temporarily unavailable due to optimisations" and I am unable to inspect most classes, lists and arrays.
I've opened the project in Xcode and set the compiler optimisations to "none" then opened it in AppCode. I've also tried opening the project in Xcode from within AppCode (File->Open project in Xcode). Despite the project properties showing no optimisations, I am still unable to view most variables. I also get variables repeated in the debug window and the execution point jumps all around the code when stepping. This leads me to believe that optimisations are still turned on.
I've tried with GDB and LLDB via debugging preferences in AppCode.
Can anyone rescue my sanity?
Thanks
Simon
Have you checked that the Run/Debug configuration you're using (in AppCode) is a Debug (and not a Release) configuration? Run -> Edit configurations pops up a dialogue where you can edit each config. Make sure that the 'configuration' drop-down is set to 'Debug'.