clion debugger stops working after one step - c++

I have a weird problem with the CLion debugger.
When I put a breakpoint or two and then hit the debug button, the debugger would initialize and stop at the first breakpoint. But then when I hit any of the step buttons in the console (Step Over, Step Into), it executes the line and then it won't allow me to step any more. The debugging process is still on, but I can't in fact do anything.
It's worth mentioning that this problem occurs only with projects that I create in CLion in my computer. When a friend creates a new CLion project and shares it with me, the CLion debugger works just fine when I use it with this project in the same computer (mine).
Any clue would be appreciated!

I ran into the same problem, and it turned out single-stepping worked only for the first few lines of code - until I called gethostname() followed by WSACleanup(). When one of them was commented out, the single stepping worked fine (F7/F8).
This is on a Windows 10 machine, and the functions are part of Microsoft's WinSock implementation.

Related

CodeLite closes terminal instantly

I'm a beginner in C++ and I started an Udemy course. In that course they recommend using CodeLite as IDE, so I decided to give it a try. In the course, they write a basic program that displays "Hello world!" to show how the IDE works. They compile then execute it, and a terminal window opens with the "Hello world!" message like normal.
In my case, after following the setup process step by step and using the exact same code as them, when I compile and execute the code, my terminal flashes for a split second and then disappears. In their video the terminal remains open but I thought that since they have an older version of CodeLite maybe in the newer one that I have, the terminal is supposed to close by default.
I went online and found people saying that a way of keeping the terminal open is by adding #include and system("pause"); on Windows, but in my case the terminal keeps behaving the same, and CodeLite doesn't report any problems. I've also tried cin.get(); with no success.
Any idea what could be causing this problem?
I had the same problem and I did these steps to solve the problem:
Uninstalled CodeLite.
Installed MinGW correctly.
Then reinstalled CodeLite.
Then did tutorial steps: Click Scan then select MinGW.
After I did these steps, it worked normally.
I had the same problem running Codelite on OpenSuse Leap 15.1. I eventually found a very simple answer. Go to the Settings menu, select Preferences and then Terminal, on the left towards the bottom. Change it to konsole to use the standard terminal, rather than the codelite-terminal.
I know this is an old question, but did not see the answer that worked for me. Debugging (F5) will close the terminal after completion.
However, running/executing (CTRL+F5) will not. Leaves terminal open. At least this is the case for me, and hopefully this helps someone out.
I know this is an old question, but CodeLite has a Project-level setting for "pause when execution ends" which will pause the program before the terminal closes so that you can see outputs and the like.
To turn on just right click on your project, go to settings, and it should be in the center of the general tab.
I went online and found people saying that a way of keeping the terminal open is by adding #include and system("pause");
And this is the wrong way to do it - the desire to leave the window open/closed is not meant to be controlled by your program; but the thing calling it. For example, you break the ability to run it as part of a headless script.
Much better would be to run it in debug and put a break point at the return of main, or to find the configuration option in your IDE that stops it closing the window.
I am not aware why CodeLite would behave like that. If you really added some pause or blocking call and it still closes, it looks like it is not really running the program (e.g. something breaks before that or something is misconfigured).
First, try to open a terminal yourself (e.g. cmd or PowerShell on Windows), and execute your compiled program there -- that way, the terminal will remain open. If that works, then compilation went fine, but something is wrong with CodeLite's configuration, most likely.
Otherwise, as a last resort, since using CodeLite is not strictly required, simply switch to another IDE/toolchain, e.g. Visual Studio (on Windows).
For some reason, after closing and reopening CodeLite, it now works, the terminal remains open when I run it from the IDE. I don't know what solved the problem since I've closed and reopened CodeLite at least 5 times before this without anything happening. Thanks for the help though.
I had the same issue. What I found wrong was that the compiler that I installed was 32bit and I was using the 64bit CodeLite version . Try Installing the 32bit CodeLite version and it should work fine.
It worked for me.
I had this problem also, I tried uninstalling and reinstalling code lite but the problem still occurred.
I went back and checked the Environment Variables in control panel and I had placed the systems variables in "Path" to the incorrect Bin directory.
I corrected the entry, uninstalled and reinstalled code lite again and the problem was resolved.
Hey I also had the same problem, doing the same course! What I did was to relocate my mingw-w64 folder, deleted the earlier path from environment variables and added the new path. I uninstalled CodeLite; not saving the user information. I actually downloaded the 14.0.0(64-bit) instead of the newer version 14.0.1(64 bit) . Then I did the steps that Frank tells you and it worked out for me.
I am completing the same Udemy course and encountered a similar problem of the console closing immediately. I encountered the problem for a workspace with 1.) a long name and 2.) ending with an underscore "_". I reduced the size of the folder name which also involved deleting the trailing underscore. This appears to have solved the problem. I encountered this problem with one of Frank's provided workspaces so I knew it was not a compiler issue.
I had an issue with section 20 of my Udemy course because it had parenthesis in the workspace folder name. "(STL)" at the end. Once I got rid of the special characters, it worked fine.
If pause("system"); or cin or restarting Program and whole PC solutions are not working, then make sure to:
Copy your code.
Create new Project and past your code there.
Make sure the new project is selected before trying to double-click it.
Notes:
You can now delete the old not working project and rename your new project.
I don't know what's the reason of the problem, but I did that and it worked for me.
You need to make sure if it is 64bits CodeLite then you have installed 64bits MinGW. Through the IDE itself, you can re-run the setup wizard
Restarting Codelite worked for me ...

Console Window does not appear using Dev C++

When I compile and run my code, the console window no longer shows up.
(I have "system("pause");" included, this is not the issue).
I was trying to debug a program in Dev C++ and must have changed some settings. Any advice?
Dev-C++ is really old and the debugger is full of bugs. If you're sure the problem isn't with your code, then I'm assuming you've tried the basics, like restarting Dev-C++ and restarting the computer?
If that doesn't work, try reinstalling Dev-C++... It only takes a couple seconds to install it.
You can also try stepping the code.

Netbeans v7 C++ debugger bug

I have a program that I have written in C++ under linux (Ubuntu 10.10).
The programming and debugging worked perfectly until the moment I added the following lines to the code:
mapfile = fopen(map_filename,"wb");
fwrite(map_header,1,20,mapfile); // <-- this is the problem line
fclose(mapfile);
After I added those, the program compiles ok, but the debugger now won't start. It immediately fails with this message:
Program completed, Exit code 0x177
error while loading shared libraries: unexpected PLT reloc type 0xcc
And if I remove the line with the "fwrite", the debugger will start normally.
This problem only happends inside Netbeans.
When I debug it using the command-line "gdb" it also works ok without any problems.
Anyone have idea why its happening and how to fix it?
P.S: Those problems started recently so I assume maybe it has to do something with system updates, I'm not sure.
Found the problem:
Not long ago, I removed some old C++ projects from netbeans. It figures out that netbeans (at least v7.0) remembers all the breakpoints that I put on old projects that don't even exist in the IDE anymore.
I found this by looking at the Debugger Console (Window->Debugging->Debugging Console) and seeing that when "gdb" starts, it tries to setup all these breakpoints from other projects or from projects that do not exists (this is a bug in netbeans, btw)
The solution: I simply cleaned all the breakpoints (inside Window->Debugging->Breakpoints) and now the program can be debugged properly.
Hope this will help to anyone out there who has the similar problem.

Making C/C++ eclipse working

I do use to work in Eclipse cause i find it pretty good, but every day i am encountering this problem..."'Cleaning all projects has encountered a problem'. Errors occured during the build." when I hit the "clean projects" button. I have win 7 64 bit.
The only solution for this issue to work is to restart my computer. But I don't find it that good, because even if I restart my computer in the next 5 minutes when I compile a certain program it gets stuck again, it shows the same annoying message.
Please give me a solution to make this work. I wouldn't like to switch to visual studio...
It's hard to tell for sure, but your application might have some unreleased resources which 'clean' command can't remove. Did executable process terminate? If not, you whould have this error. You could try to remove binaries from build folder manually and see what file causes and error.

How to ignore breakpoints in DLLs in Visual Studio

I'm using a 3rd party dll with no source code available. It runs perfectly fine, but every time I run my program, an annoying pop-up says "MyProgram.exe has triggered a breakpoint".
If I press continue, my program runs 100% correctly.
If I press break, I can see that the breakpoint is occurring in the 3rd party file alp41basic.dll
I have no clue why they put breakpoints in their dll. How can I disable them?
My question is identical to one that went unanswered:
https://stackoverflow.com/questions/17514072/is-there-a-way-to-make-visual-studio-continue-when-an-exception-occurs-on-a-line
I eventually checked in with the company that distributed the dll, and indeed there are breakpoints in there for reasons that I won't get into. However, if I run the program outside the debugger (even simply open the binary from windows), these popup windows do not occur.
Thank you all for your help!