Blog Blog
Home
Home/CLion/Debugging in CLion

Debugging in CLion

Dmitri Nesteruk

One of the key advantages to having an IDE instead of a plain-text editor is the debugging experience. Debugging involves being able to pause program execution at an arbitrary point and having the ability to inspect the content of variables.

CLion supports the debugging experience using the GDB debugger (and LLDB on OS X since version 1.1 and on Linux since version 2016.2). Here’s a look at some of the core debugging features that are supported.

Upd. (changes since CLion 2016.1 and 2016.2)
Learn how to attach for debug to local process started not from the CLion (from CLion v2016.1).

Check major changes (since v2016.2) in GDB and LLDB drivers and addresses such problems as:

  • Command timeouts.
  • Stepping problems.
  • Debugger performance issues.

Please, find more details in our blog post by the link.

Try remote GDB debug (since v2016.2).

Breakpoints

In order to inspect the state of the program at a particular point, you need to pause the program. Breakpoints are used for exactly this purpose.

A simple breakpoint stops the execution of a program at a particular line. To make one, simply press Ctrl+F8 (Windows/Linux)/⌘F8 (OS X) or, alternatively, click the mouse in the grey gutter area to the left of the code. The line with the breakpoint will be highlighted, and the breakpoint itself will appear as a red circle:

Now, when you run the program in debug mode (by choosing the menu item Run|Debug or pressing Shift+F9 (Windows/Linux)/^D (OS X)), program execution will stop at the line you selected.

A conditional breakpoint will only stop at a particular line if some condition holds. To edit the condition, you can right-click the breakpoint and type in the condition in the window that pops up. You even get code completion right in the editor!

2

With this pop-up window open, you can press Ctrl+Shift+F8/⇧⌘F8 to open up the full breakpoint editing window:

3

Some of the options available here include:

  • Suspend — this check box determines whether the execution pauses at a particular point or not. Leaving this unchecked means program execution will continue, but any breakpoint rules (e.g., logging) will still be executed.
  • Condition — determines the condition on which this breakpoint triggers. Leaving this out ensures that the breakpoint is always hit.
  • Log message to console writes to the console information about the breakpoint being hit.
  • Log evaluated expression lets you log the result of specific evaluation.
  • Remove once hit ensures that after you hit the breakpoint once, the breakpoint is removed. This can be useful in cases where you only want to log the first occurence of a particular point being hit.
  • Disabled until selected breakpoint is hit does exactly what it says: it disables the current breakpoint until some other breakpoint is encountered. This is useful in situations where, for example, you only want to investigate a point in code when it is called from a specific function of your choosing. There are two options here:
    • Disable again disables the breakpoint after it is hit until the dependant breakpoint is hit again (in which case it is re-enabled).
    • Leave enabled leaves the breakpoint forever enabled and thus no longer dependant on any other breakpoint being hit first.

Exception Breakpoints

But that’s not all! In addition to ordinary breakpoints, CLion also supports exception breakpoints which, as the name suggests, trigger when the program throws an exception.

The set of options related to exception breakpoints is similar to line breakpoints: you can specify whether you want to suspend execution, log message to the console, remove the exception once it’s hit, or only enable it when some other breakpoint is hit first:

4

Debugger User Interface

So, what exactly happens when a debugger hits a breakpoint? Apart from the execution pausing, you get to see the following Debug tool window:

There’s a lot going on here, so let’s start by discussing the two primary tabs (the top-level tabs, so to speak). They are:

  • Debugger — this actually shows the various debugging options that we are going to discuss in just a moment.
  • Console — this area shows the command-line output, if your application has any.

Directly to the right of these tabs is a set of buttons that allow you to navigate around the code being debugged. They include letting you

  • Show Execution Point (Alt+F10),
  • Step Over (F8),
  • Step Into (F7),
  • Force Step Into (Alt+Shift+F7),
  • Step Out (Shift+F8),
  • and Run to Cursor (Alt+F9).

There’s also a button that lets you Evaluate Arbitrary Expression (Alt+F8) — we’ll talk about this later.

To the left of the tabs is a vertical column of buttons that contains higher-level controls for debugging, including buttons for resuming execution or stopping the application, an ability do display breakpoint settings, and other miscellaneous controls.

So let’s get back to the Debugger tab. This tab has lots of things going on. First of all, on the left, it lets you actually pick the threads that you want to inspect. Modern applications run on many threads, so you can pick one from a drop-down list:

Directly below that is the stack frame, i.e., a list of the nested functions that were invoked as you were going through the code. Each entry lists the full name of the function (or constructor), the file name and the line number. Clicking the line causes CLion to open the corresponding file at the specified line number:

7

To the right of the stack frame, we have two tabs: Variables and GDB (LLDB). We’ll talk about variables in just a moment; as far as GDB (LLDB) is concerned, this tab essentially shows the command-line output from GDB (LLDB) itself, since that’s the debugger that’s being used to debug our app.

Variables

The simplest way to view the state of a variable is, of course, in code. Simply hover the mouse over the variable in question and you should see something like the following:

If you press Ctrl+F1 (Windows/Linux)/⌘F1 (OS X) at this point, a window will pop up containing the inner states of the variable you are after:

Of course, you get a more comprehensive view of variables in the Debug tool window. For a chosen function in the stack frame, the Variables tab shows the state of all the variables. In a complicated application, it can get quite busy:

For any one variable we can expand the tree to see its contents:

If you want to cut out the noise a little bit, simply right-click the variable and choose Inspect: this opens up a separate window for inspecting this variable only:

It is entirely possible to actually alter the values of the variables in the debug session. Right-click the variable and choose Set Value. The editor will open in-place over the current value, letting you type in the new value:

GNU STL Renderers

As a special enhancement of the debugging experience, CLion treats STL containers with extra care, making sure you get the best possible representation during the debug process. For example, here’s a look at how an std::map can be presented in the debugger:

This feature works in GCC, and in the case of Clang it works for libstdc++ only. This requires the following setting to be added to CMakeLists.txt:

set(CMAKE_CXX_FLAGS “${CMAKE_CXX_FLAGS} -stdlib=libstdc++”)

Watches

Capturing every single variable at every single point results in far too much information. Sometimes, you want to focus on a specific variable and the way it changes throughout program execution, including monitoring changes when the variable in question is not local to the code you are inspecting. This is what the Watch area of the Debug tool window is for.

To start watching a variable, simply press the Add button (Alt+Insert (Windows/Linux)/⌘N (OS X)) and type in the name of the variable to watch. Code completion is available here too.

Alternatively, pick an existing variable, right-click it and choose Add to watches. Now the window will keep displaying the value of the variable even if you are in some nested part of the stack frame:

Evaluating Expressions

You can see variable states on a breakpoint, but what if you want to see the sum of two variables, or evaluate the result of a function call then and there? There’s functionality for that too. Simply press the Evaluate Expression button (Alt+F8) on the Debug tool window and type in your expression. As always, you get code completion here, and after you press the Evaluate button, the result area below will display the result of the evaluation:

You can also use a shortcut (Ctrl+Shift+Enter) to add this expression to watches. That’s right – watches can contain arbitrary expressions, not just single variables!

Watch CLion debugging features in action:

https://www.youtube.com/watch?v=wUZyoAnPdCY

Conclusion

This post has shown what CLion can do for you when debugging. You can evaluate these features for free for 30 days, simply download the build from our site. Give it a go, and let us know what you think! ■

#Debug
Comments below can no longer be edited.

153 Responses to Debugging in CLion

  1. mwb says:

    May 8, 2015

    This is an awesome IDE for gcc/g++ right now.

    I would love to be able to connect a debug session remotely to a gcc/g++ application running on a cross-compiled ARM embedded target.

    Please support that at some point (soon).

  2. Christian Sell says:

    May 11, 2015

    debugging from within Clion doesn’t work at all on my Linux Mint 17 machine with gcc 4.8.2. It doesn’t show variable data, sometimes my application gets terminated with some “command timeout” message, and more of the same.

    Note that this is a standard out-of-the-box OS installation, and Clion has not been tweaked either. Note also that debuggin from within QtCreator works flawlessly (thank God)

  3. Karel says:

    June 6, 2015

    Hi, would it be possible to add a functionality similar to Image Watch for Visual Studio ( http://opencv.org/image-watch-plugin-for-visual-studio.html )? It would be incredibly helpful for me (and I believe also for others) :).

    Thanks.

    • Anastasia Kazakova says:

      June 8, 2015

      Thanks for the suggestion. I’ve added it to the tracker (https://youtrack.jetbrains.com/issue/CPP-3659). You can follow to get the updates, upvote, comment. Still this doesn’t look like a top prio task for now, but we’ll consider it for later. Thanks again.

  4. Serge says:

    June 10, 2015

    Inject CUDA debugger in your IDE and it will be perfect product.

  5. rapha says:

    June 11, 2015

    CLion looks awesome and I guess I’ll soon offer myself yet another Jetbrain license. Though There is a feature I can’t find anywhere in documentation.

    One of the most useful feature of a debugger when multiple threads walk on each other toes is “data breakpoint”:

    http://blogs.msdn.com/b/visualstudioalm/archive/2013/10/14/data-breakpoints.aspx

    It enables you to find who the hell is overriding your favorite variable in a matter of seconds! I can’t count how often I’ve used this in Visual Studio.

    Does such feature exist in CLion ?

    • Anton Makeev says:

      June 12, 2015

      Data breakpoints are called watchpoints in GDB and supported in CLion: right-click on any variable and select ‘Add Watchpoint’.

      • Christian says:

        February 4, 2016

        I don’t see “Add Watchpoint” when I right-click a member variable. Bug or not supported?

        • Anastasia Kazakova says:

          June 9, 2016

          If you still experience the problem, please, submit some description to our tracker.

          • Benm says:

            November 30, 2016

            For me this feature is also missing. I submitted this issue to the tracker https://youtrack.jetbrains.com/issue/CPP-8309.
            Please upvote by pressing the little thumb if you also want this feature.

            • Anastasia Kazakova says:

              November 30, 2016

              Thanks for creating a request!

  6. Dan says:

    June 14, 2015

    So far I am very impressed with the quality of Clion. Well done!

    Debugging visualizers: You mention you pay special attention to STL classes to display them nicely in the debugger. I am using Clang, with stdlib=libc++, not libstdc++, so i am not getting the pretty debugging visualization as you note above.

    Is it possible for me to write my own? Because this would in general not just apply to STL classes, but to any classes, even user created ones. In Visual Studio this is called Visualizers. Is there something similar already in CLion, or planned for the future?

    • Anastasia Kazakova says:

      June 15, 2015

      Because CLion uses GDb as a debugger now, you can provide a custom GDB extension and set it in gdbinit.

      • Daniel Colceag says:

        September 26, 2017

        Where should the .gdbinit file be stored ?
        I tried under /home/[user]/.gdbinit and /path/to/clion/bin/gdb/.gdbinit and it didn’t work. I have a special function that shows unicode strings in gdb

        • Eldar Abusalimov says:

          September 26, 2017

          `~/.gdbinit`, that is `/home/[user]/.gdbinit`, should work.

          • Luis says:

            May 14, 2018

            In the home directory it works, but shouldn’t it work also putting the file in the build directory, “cmake-build-debug”?

            I’m trying to enhance the clion integration with conan with a new conan generator that generates a “. gdbinit/.lldbinit” file containing the paths of the source code for the dependencies. But copying the “.gdbinit” file to the userhome doesn’t feel good. The config files should be taken from the build directory. In which folder is the debugger launched? gdb/lldb take these files from the current folder automatically.

          • David says:

            July 12, 2019

            Anny new approach, can anyone support a example für debugging with avr-gdb and /.gdbinit?

          • elmot says:

            July 14, 2019

            @David, not yet. But we’re planning that.

  7. Peter Kolski says:

    June 15, 2015

    Unfortunately I can’t get the debugger to work correctly at all. No variables values are appearing. The types are shown correctly.
    I use CLion 1.0.3, Mac OS 10.10.3. Bundled GDB 7.8 is activated.
    First usage of a debugging session Mac OS is asking for permissions to allowing control over the software to debug, which I allow.

    Hope there is a quick fix, because debugging is quite crucial for productive software development.
    Thank you!

    • Anastasia Kazakova says:

      June 15, 2015

      Could you provide some screenshot or some sample to reproduce. Send it to clion-support at jetbrains.com please. We’ll get in touch asap.

    • Peter Kolski says:

      June 17, 2015

      Hello! Did you get my mails? Thank you

      • Anastasia Kazakova says:

        June 17, 2015

        Yes. Sent you the answer already.

        • Mikhail Sirotenko says:

          July 27, 2015

          I experience exactly the same situation on Mac. Just in my case I get “command timed out” message. Have you fixed it yet?

          • Anastasia Kazakova says:

            July 28, 2015

            What version are you using? If 1.0.5 (the latest update) then please share the debug log: collect debug logs (Help | Configure Debug Log | Add #com.jetbrains.cidr.execution.debugger) while starting a session and send to us (logs can be found in Help | Show Log) to clion-support at jetbrains.com. It should be fixed, but if you still get it, please, provide some log to us, will have a look.

          • Anastasia Kazakova says:

            June 9, 2016

            Could you please try this build: https://blog.jetbrains.com/clion/2016/06/clion-2016-2-eap-debugger/ and share if the problem is still there.

    • Anastasia Kazakova says:

      June 9, 2016

      Could you please try this build: https://blog.jetbrains.com/clion/2016/06/clion-2016-2-eap-debugger/ and share if the problem is still there.

  8. Mayra Albuquerque says:

    August 16, 2015

    Hi everyone,
    How do I watch the values of an vector? When I add to watches it is showed the pointers.

    • Anastasia Kazakova says:

      August 16, 2015

      What do you see in Variables tab? Do you have GNU C++ library renderers ON in settings Build, Execution, Deployment | Debugger? What OS/compiler/standard library do you use?

      • Mayra Albuquerque says:

        August 19, 2015

        Hi Anastacia,
        Thank you for answer.

        The new version of Clion 1.1 changed the debugger from GDB to LLDB.
        With this, I can see the values now.

        • Anastasia Kazakova says:

          August 19, 2015

          Great. Happy to hear that.

  9. Paul Kramme says:

    August 21, 2015

    Hey there!
    Is it possible to open up a console window when you run the program, instead of using the build in window?

    • Anastasia Kazakova says:

      August 24, 2015

      No, it’s not. And why do you need it? What’s the use case?

      • Artyom says:

        February 22, 2016

        Well, sometimes I need to put the end-of-file marker (aka ctrl-z in Windows) and I can’t do it in the built-in window but in console. Using alt+026 puts this “→”. I guess, it isn’t the eof-marker.
        Probably, you can suggest another way to put marker. It would be nice too.

        • Anastasia Kazakova says:

          February 22, 2016

          Have you tried Ctrl+D?

          • Artyom says:

            February 23, 2016

            Oh. Thanks

      • Viktor says:

        April 7, 2016

        Dear Anastasia,
        I have the same request. I am developing a console application that uses ncurses library for text “formatting”, and the output of the built-in window is incorrect for colored text at least on OS X.

        • Anastasia Kazakova says:

          April 7, 2016

          Viktor, I believe this is connected to the following problem: https://youtrack.jetbrains.com/issue/CPP-822

          • Viktor says:

            April 9, 2016

            Dear Anastasia,
            thank you for the answer. Indeed, the problem is described as what I’m experiencing is. I guess, the best solution might be having an option “debug in a new window” or “run in a new window” along with “debug” and “run” options. Having said that, currently it is almost possible by having a terminal win a running debug application and attaching CLion using remote debugging. If you had an option of running an application in a separate terminal session and attaching to it automatically, that would be awesome.

          • Viktor says:

            April 9, 2016

            The problem described in https://youtrack.jetbrains.com/issue/CPP-822 is partially solved by exporting a “TERM” environment variable in configuration settings, i.e.: “TERM=xterm”

            • Anastasia Kazakova says:

              April 9, 2016

              ok, thanks for the update

  10. czheji says:

    August 21, 2015

    When I debug my code ,It’s very slow.Logs show an error happend:
    clion1.1
    gdb 7.8 (bundled)
    archlinux with rf kernel(4.1.2-pf #1 SMP PREEMPT Wed Aug 12 14:24:15 CST 2015 x86_64 GNU/Linux)

    logs:
    2015-08-21 18:08:16,348 [ 849897] INFO – #com.jetbrains.cidr.lang – myckeys_test.cpp: DFA time is over
    2015-08-21 18:08:16,604 [ 850153] INFO – brains.cidr.execution.debugger – Debugger started
    2015-08-21 18:08:22,870 [ 856419] WARN – brains.cidr.execution.debugger – >-var-create – * “idSize”
    2015-08-21 18:08:22,870 [ 856419] WARN – brains.cidr.execution.debugger – -var-create – * “idSize”
    2015-08-21 18:08:27,980 [ 861529] WARN – brains.cidr.execution.debugger – -var-create – * “idSize”
    2015-08-21 18:08:33,566 [ 867115] WARN – brains.cidr.execution.debugger – -var-create – * “idSize”
    2015-08-21 18:08:38,677 [ 872226] WARN – brains.cidr.execution.debugger – -var-create – * “idSize”
    2015-08-21 18:08:43,983 [ 877532] WARN – brains.cidr.execution.debugger – -var-create – * “idSize”
    2015-08-21 18:08:49,316 [ 882865] WARN – brains.cidr.execution.debugger – -var-create – * “idSize”
    2015-08-21 18:08:54,549 [ 888098] WARN – brains.cidr.execution.debugger – <^error,msg="-var-create: unable to create variable object"
    2015-08-21 18:08:58,972 [ 892521] WARN – brains.cidr.execution.debugger – Cannot detach/abort. Forcing driver termination
    2015-08-21 18:08:58,990 [ 892539] INFO – brains.cidr.execution.debugger – Execution finished
    com.intellij.execution.ExecutionException: Execution finished
    at com.jetbrains.cidr.execution.ExecutionResult.get(ExecutionResult.java:51)
    at com.jetbrains.cidr.execution.debugger.backend.gdb.GDBDriver.executeCommand(GDBDriver.java:2247)
    at com.jetbrains.cidr.execution.debugger.backend.gdb.GDBDriver.executeCommand(GDBDriver.java:2242)
    at com.jetbrains.cidr.execution.debugger.backend.gdb.GDBDriver.getVariables(GDBDriver.java:1334)
    at com.jetbrains.cidr.execution.debugger.CidrStackFrame$3.run(CidrStackFrame.java:143)
    at com.jetbrains.cidr.execution.debugger.CidrDebugProcess$MyCommandProcessor.consume(CidrDebugProcess.java:678)
    at com.jetbrains.cidr.execution.debugger.CidrDebugProcess$MyCommandProcessor.consume(CidrDebugProcess.java:671)
    at com.intellij.util.concurrency.QueueProcessor$2$1.run(QueueProcessor.java:110)
    at com.intellij.util.concurrency.QueueProcessor.runSafely(QueueProcessor.java:238)
    at com.intellij.util.concurrency.QueueProcessor$2.consume(QueueProcessor.java:107)
    at com.intellij.util.concurrency.QueueProcessor$2.consume(QueueProcessor.java:104)
    at com.intellij.util.concurrency.QueueProcessor$3$1.run(QueueProcessor.java:215)
    at com.intellij.util.concurrency.QueueProcessor.runSafely(QueueProcessor.java:238)
    at com.intellij.util.concurrency.QueueProcessor$3.run(QueueProcessor.java:212)
    at com.intellij.openapi.application.impl.ApplicationImpl$8.run(ApplicationImpl.java:400)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
    at org.jetbrains.ide.PooledThreadExecutor$1$1.run(PooledThreadExecutor.java:56)
    Caused by: com.intellij.execution.ExecutionFinishedException: Execution finished
    at com.jetbrains.cidr.execution.debugger.backend.gdb.GDBDriver.sendRequest(GDBDriver.java:1874)
    at com.jetbrains.cidr.execution.debugger.backend.gdb.GDBDriver.sendRequestAndWait(GDBDriver.java:1857)
    at com.jetbrains.cidr.execution.debugger.backend.gdb.GDBDriver.sendRequestAndWait(GDBDriver.java:1849)
    at com.jetbrains.cidr.execution.debugger.backend.gdb.GDBDriver.a(GDBDriver.java:1606)
    at com.jetbrains.cidr.execution.debugger.backend.gdb.GDBDriver.a(GDBDriver.java:1561)
    at com.jetbrains.cidr.execution.debugger.backend.gdb.GDBDriver.a(GDBDriver.java:1376)
    at com.jetbrains.cidr.execution.debugger.backend.gdb.GDBDriver.access$7300(GDBDriver.java:45)
    at com.jetbrains.cidr.execution.debugger.backend.gdb.GDBDriver$30.run(GDBDriver.java:1341)
    at com.jetbrains.cidr.execution.debugger.backend.gdb.GDBDriver$30.run(GDBDriver.java:1334)
    at com.jetbrains.cidr.execution.debugger.backend.gdb.GDBDriver$36.run(GDBDriver.java:2274)
    at com.intellij.util.concurrency.QueueProcessor$RunnableConsumer.consume(QueueProcessor.java:298)
    at com.intellij.util.concurrency.QueueProcessor$RunnableConsumer.consume(QueueProcessor.java:295)
    … 14 more
    2015-08-21 18:08:59,010 [ 892559] INFO – brains.cidr.execution.debugger – Debugger exited with code 0
    2015-08-21 18:09:02,202 [ 895751] INFO – #com.jetbrains.cidr.cpp – Executing CMake: /home/czj/tools/clion-1.0.5/bin/cmake/bin/cmake -G "Unix Makefiles" /tmp/cmake_check_environment0.tmp
    2015-08-21 18:09:14,278 [ 907827] INFO – #com.jetbrains.cidr.lang – myckeys_test.cpp: DFA time is over
    2015-08-21 18:09:14,765 [ 908314] INFO – #com.jetbrains.cidr.lang – myckeys_test.cpp: DFA time is over
    2015-08-21 18:09:30,532 [ 924081] INFO – #com.jetbrains.cidr.lang – myckeys_test.cpp: DFA time is over
    2015-08-21 18:09:31,001 [ 924550] INFO – #com.jetbrains.cidr.lang – myckeys_test.cpp: DFA time is over
    2015-08-21 18:09:59,296 [ 952845] INFO – ellij.concurrency.JobScheduler – 50 ms execution limit failed for: com.intellij.openapi.progress.impl.CoreProgressManager$1@5f3dd194; elapsed time was 173ms

    • czheji says:

      August 21, 2015

      codes:

      #include
      using namespace std;
      int main() {
      cout << "Hello, World!" << endl;
      unsigned char hello[2048]={0};
      for(int i=0;i<2048;i++){
      hello[i]=i%256;
      }
      int i=20;
      int j=30;
      int t=i+j*2;
      cout<<"t="<<t<<"hello="<<hello[302]<<endl;
      return 0;
      }

      when debug step in loop ,"WARN – brains.cidr.execution.debugger – Cannot detach/abort. Forcing driver termination"

    • Anastasia Kazakova says:

      June 9, 2016

      Could you please try this build: https://blog.jetbrains.com/clion/2016/06/clion-2016-2-eap-debugger/ and share if the problem is still there.

  11. Alexey Ushakov says:

    August 24, 2015

    Thanks for reporting this. It looks like a known issue (https://youtrack.jetbrains.com/issue/CPP-3627) that we’re currently working on. However to make sure that it is your case could you please send us full logs of debugging (you can attach them to the issue I’ve provided). Just put 

    #com.jetbrains.cidr.execution.debugger

    into Help -> Configure Debug Log Settings . The logs will be at Help -> Show Log in Files

  12. Benjamin Golinvaux says:

    August 28, 2015

    Hello

    So far, I’m very happy with CLion. I’m running latest 1.1.

    My only real issue currently is that, when starting to debug my executable, I need to wait for 45 seconds before the program really starts )and my first breakpoint is hit in main( ) )

    Very strange because when running with gdb from a bash session, startup is instantaneous.

    There are obviously gears turning under the hood, but some feedback/customization would be nice. 5 seconds would be slightly annoying, but 45 seconds is nearly a no-go for me (my dad who used punch cards would disagree but…)

    Thanks for any help you can provide

    Best
    Benjamin (Belgium)

    • Alexey Ushakov says:

      August 28, 2015

      Could you send us your logs? You need to put

      #com.jetbrains.cidr.execution.debugger

      into Help -> Configure Debug Log Settings . The logs will be at Help -> Show Log in Files

    • Anastasia Kazakova says:

      June 9, 2016

      Could you please try this build: https://blog.jetbrains.com/clion/2016/06/clion-2016-2-eap-debugger/ and share if the problem is still there.

  13. Igor Tkachuk says:

    September 22, 2015

    Hello! I have some problem: Clion duplicates and reprinting all input data. How can I turn it off?

    • Anastasia Kazakova says:

      September 23, 2015

      Could you please provide more details on the problem? OS, CLion version, some code sample? Send it pls to clion-support at jetbrains.com and we’ll see what’s going on for you there.

      • Igor Tkachuk says:

        September 23, 2015

        Anastasia it is my code:
        #include
        #include

        using namespace std;

        int main() {
        cout <“;
        int a;
        cin>>a;
        cout<5
        input a–>5
        5
        Why is duplicates code input a–>5?
        Thanks you!

        • Igor Tkachuk says:

          September 23, 2015

          I’m sorry, that’s not gone

          • Igor Tkachuk says:

            September 23, 2015

            #include
            #include

            using namespace std;

            int main() {
            cout <“;
            int a;
            cin>>a;
            cout<<a;
            _getch();
            return 0;
            }

          • Igor Tkachuk says:

            September 23, 2015

            Code not sent…

  14. Igor Tkachuk says:

    September 23, 2015

    http://vk.com/wall273848965_142

  15. dibus says:

    October 22, 2015

    Hi,

    I am new to CLion. I am trying to debug a simple c++ code and none of my breakpoints that I set seems to have any effect. The code simply runs through them without stopping. I am running version 1.1 on Mac OS X 10.10.5.

    Any idea what could be the issue?

    Thanks,

    • Anastasia Kazakova says:

      October 23, 2015

      Are you using default LLDB or switched to GDB?
      Could you send the project to reproduce and share with us what you do to debug, step by step. Are you pressing Run or Debug button? How do you set breakpoints? Maybe you can create short video to show us the case?

      • dibus says:

        October 23, 2015

        Hi,

        I have tried both GDB and LLDB and the same occur with both. Also, I have a different project with which it stops just fine.
        I am indeed using the debug button and setting `Configuration` to Debug in the configuration. I set the breakpoints by clicking in the grey margin on the left.

        data-url=”http://lpsc.in2p3.fr/lyonnet/shared/Debug.mov”

        • dibus says:

          October 23, 2015

          Hi I have found the problem actually. I had a set(CMAKE_BUILD_TYPE RELEASE) in my CMAKE and despite the debug option in the configuration it would not stop. Removing this unwanted statement solved my issue. Thanks for your support and reactivity.

  16. dibus says:

    October 23, 2015

    Hi,

    Is it possible to debug a library compiled within CLion but called from a python script?

    To be more specific, I have a fortran/c++ project that I compile into a library from CLion. Then I call this library from python using ctypes and I would like to be able to debug the underlying fortran/c++ code with CLion.

    After compiling the library I created a configuration file that calls my python script. I can execute this liking the play button without any trouble. However, If I try to debug it then I obtain a couldn’t create target error message.

    I attach a the video: .

    • Anastasia Kazakova says:

      October 26, 2015

      Currently it’s not possible. You need attach to process functionality for this, that’s not ready yet: https://youtrack.jetbrains.com/issue/CPP-1001

      • Jared says:

        March 14, 2016

        So now that attach to process is available (well, in the EAP version of CLion), how can we debug cpp code called from Python ctypes?

        • Anastasia Kazakova says:

          March 14, 2016

          Currently you can connect to the local process either with Python or with C/C++ debugger. It’s not possible to connect with one to debug both. So most likely it will be working in case of CPP-process you can try to connect to, that is called via ctypes. If you try, we’ll be glad to listen to your feedback and experience.

          • Dan says:

            March 23, 2018

            With CLion 2017.3, it is possible and works well.
            In fact you can debug at the same time the python code and the underlying C++ code, all with CLion.
            To do this you need to first start debugging the python code, and then “Attach to local process”, and select the python process. You will effectively have two debuggers – one for the python code and one for the C++, in two different tabs within CLion.

            Note however, you cannot “step into” directly from the python ctypes call into C++, you need to attach and set a breakpoint in the C++ code.

  17. Kathleen McCandless says:

    December 2, 2015

    I’m using CLion 1.2.1 and would like to get the debugger functionality working. I am using the bundled gdb and cannot get it working, I get a connection timed out error message.

    /g/g15/kmccandl/Phoenix/vbl-upgrade/miniapp/build/Debug/testpropagator
    Command timed out

    The GDB dialog says:

    GNU gdb (GDB) 7.8
    Copyright (C) 2014 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law. Type "show copying"
    and "show warranty" for details.
    This GDB was configured as "x86_64-unknown-linux-gnu".
    Type "show configuration" for configuration details.
    For bug reporting instructions, please see:
    .
    Find the GDB manual and other documentation resources online at:
    .
    For help, type "help".
    Type "apropos word" to search for commands related to "word".
    python
    >>>>>No source file named /g/g15/kmccandl/Phoenix/vbl-upgrade/miniapp/vblfourierpropagator.cpp.

    However, this file does indeed exist:

    sierra1620{kmccandl}:ls -l /g/g15/kmccandl/Phoenix/vbl-upgrade/miniapp/vblfourierpropagator.cpp
    -rw------- 1 kmccandl kmccandl 7476 Dec 2 07:19 /g/g15/kmccandl/Phoenix/vbl-upgrade/miniapp/vblfourierpropagator.cpp

    Do you know what I can do to diagnose further what is wrong?

    • Anastasia Kazakova says:

      December 2, 2015

      Are there any symlinks there? If yes, is this reproducible in case you open the project by the original path, without symlinks?

      Also debug logs can be helpful. Configure debug logs (call Help | Configure Debug Log, add #com.jetbrains.cidr.execution.debugger in the windows),collect them while starting a session and send to us (logs can be found in Help | Show Log) to clion-support at jetbrains.com.

      • Thomas Schulz says:

        December 18, 2015

        Did you find a solution for this? I am having a similar problem in CLion 1.2.2. I get the same “No source file named…” message for the file where I set the breakpoint. The debugger therefore does not stop at the breakpoint.

        • Anastasia Kazakova says:

          December 18, 2015

          We didn’t get any logs or answers, as far as I know. Could you please check about the symlinks (as I asked above)? And send logs to us as described.

        • Anastasia Kazakova says:

          December 18, 2015

          Thanks for the logs. As I’ve replied in the email, I’ve put it into https://youtrack.jetbrains.com/issue/CPP-5415.
          Could you also check if it works with the debugger from the system (not the bundled one)? Please, reply in the corresponding ticket, if possible.

          • Thomas Schulz says:

            December 28, 2015

            I found the issue, but it was on our side. We have code in our cmake file that sets the build type depending on the directory that cmake is called from (debug or release). This code defaults to release if it can’t match the directory that cmake is called from (which it can’t since CLion uses its own directories). So the ticket might be invalid.

            Nevertheless, I would really like to be able to set the directory cmake is called from. Are you planning to add this in the future?

    • Anastasia Kazakova says:

      June 9, 2016

      Could you please try this build: https://blog.jetbrains.com/clion/2016/06/clion-2016-2-eap-debugger/ and share if the problem is still there.

  18. Marchorse says:

    December 31, 2015

    Hi,
    When debugging a project, I met the annoying “Command timed out” problem with Clion 1.2.4, no matter whether I used the bundled gdb(7.8) or the host gdb(7.10.1). The debugger window just showed the information “collecting data” and gdb was eating a lot of memory and cpu resources, but no further information came and the debug operation disabled.
    How could this problem be resolved?

    • Anastasia Kazakova says:

      December 31, 2015

      Could you please collect debug logs as described here (https://intellij-support.jetbrains.com/hc/en-us/articles/206560589) and submit a request with OS, product version and GDB versions? We’ll investigate. Thanks in advance.

      • Marchorse says:

        December 31, 2015

        Request has been submitted.Hope you guys can resolve this as soon as possible.

        • Anastasia Kazakova says:

          January 4, 2016

          Thanks. We saw it. Hope to investigate and find the reason soon.

        • Anastasia Kazakova says:

          January 4, 2016

          By the way, we asked you for the logs. Have you submitted them? Can’t find them still.

    • Anastasia Kazakova says:

      June 9, 2016

      Could you please try this build: https://blog.jetbrains.com/clion/2016/06/clion-2016-2-eap-debugger/ and share if the problem is still there.

  19. Wes Moncrief says:

    February 12, 2016

    Hi,
    I’m writing openGL code that uses some global variables. When I’m in the debugger, it won’t let me examine my global variables. I unchecked the “hide out of scope” option, but that didn’t help. What can I do to to inspect these global variables from within any function?

    • Anton Makeev says:

      February 12, 2016

      Currently, there is no dedicated view for globals, though you can use Evaluate dialog (Alt+F8) as a workaround.
      Here is a feature request that should be able to solve your case: https://youtrack.jetbrains.com/issue/CPP-4992. Feel free to leave a comment there.

  20. Danny Suen says:

    March 25, 2016

    When will the features mentioned in this EAP appear in the final release? I am in need of this attach to local processes feature as I am working on a multi-processes project. So it a pity this still can’t be seen in the current version.

    • Anastasia Kazakova says:

      March 25, 2016

      Attach to local process is available since 2016.1 release a week ago.

  21. Vipin Olikara says:

    April 14, 2016

    Hi,
    We are using CLion2016.1.1. We use GNU GDB 7.8 for debugging. Windows is our platform.
    Our most annoying problem is that while debugging
    1. Sometimes we don’t see values for some variables in the Debugger->Variables Tab.
    2. Sometimes we see values which are not the same if we compare those in the Variables & Watches Tab in Debugger.
    3. The worse case is that the values in Variables and Watches are different to what we see in console if we print the values to console.

    In short the debugger is not usable.
    We really like CLion but with this untrusty debugger we are forced to think about moving to a different IDE.
    If there is already a solution to the problem or is a known issue, please let us know the latest status.

    Appreciate any helpful reply on this.

  22. Nickname says:

    April 23, 2016

    During startup program exited with code 127.

    Process finished with exit code 0

  23. Andrew Bruce says:

    June 19, 2016

    This EAP build has been a major improvement. I am looking forward to the next release.

    • Anastasia Kazakova says:

      June 19, 2016

      Thanks!

  24. Denis Medvedev says:

    July 19, 2016

    Hi,
    CLion is a great IDE, but I experience one major issue — I work on a big project and CLion does not open some .cpp files (no visible pattern), files are not opened by double clicking in the project view, from Cmd+Ctrl+O window or by pressing Cmd+Ctrl+Up in corresponding header. I could not find any solution on the Internet so far.

    • Anastasia Kazakova says:

      July 19, 2016

      Could you please attach the screenshot of how these files look like on the project view window?

      • Denis Medvedev says:

        July 19, 2016

        Sure,
        I have uploaded it here https://i.imgur.com/HQjYFiO.png (I had to erase filenames, sorry about that)
        I can open the first and the third cpp files, but if I double click the second one nothing happens.

  25. Oran Shuster says:

    September 15, 2016

    what if i want to compile using cmake/clion but attach to a different process then the “main” one
    can i change the build configuration so it doesn’t attach itself automatically to a single process?

    • Anastasia Kazakova says:

      September 15, 2016

      To attach to any process running locally simply use Run | Attach to local process. Then select the process in the list.

  26. Roger says:

    September 20, 2016

    I am using
    CLion 2016.2.2
    Build #CL-162.1967.7, built on September 5, 2016
    On OSx 10.11.6 to debug a program on a remote linux server.
    I am using a custom build of GDB which works form the command line.

    When launching the debugger in Clion it keeps failing:
    GNU gdb (GDB) 7.11.1
    Copyright (C) 2016 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law. Type “show copying”
    and “show warranty” for details.
    This GDB was configured as “–host=x86_64-apple-darwin15.4.0 –target=x86_64-linux-gnu”.
    Type “show configuration” for configuration details.
    For bug reporting instructions, please see:
    .
    Find the GDB manual and other documentation resources online at:
    .
    For help, type “help”.
    Type “apropos word” to search for commands related to “word”.
    python
    >>>>>>>No source file named /Users/rogerblain/Documents/dataengine/src/main/core_engine.cpp.
    No source file named /Users/rogerblain/Documents/dataengine/src/main/core_engine.cpp.

    The source file does exist!

    Or O get:
    >>>>>>No source file named /Users/rogerblain/Documents/dataengine/src/main/core_engine.cpp.
    No source file named /Users/rogerblain/Documents/dataengine/src/main/core_engine.cpp.
    warning: Unable to find dynamic linker breakpoint function.
    GDB will be unable to debug shared library initializers
    and track explicitly loaded dynamic code.
    0x00007ffff7dddaf0 in ?? ()
    warning: Could not load shared library symbols for 11 libraries, e.g. /lib/x86_64-linux-gnu/libpthread.so.0.
    Use the “info sharedlibrary” command to see the complete listing.
    Do you need “set solib-search-path” or “set sysroot”?
    [Inferior 1 (process 17514) exited with code 01]

    I also need to know how to run with:
    extended-remote?

  27. jecyhw says:

    September 21, 2016

    How to view static and global variables in debug mode, rather than add to watches.

  28. Alex says:

    September 23, 2016

    I can’t find how to make breakpoints work.
    I built a library and some tests using makefile. I’d like to start tests in the debugger using Clion.
    Since makefile creates hidden folders for the binaries and I can’t specify path to the binary in Debug Configuration->Executable, I copy tests/libraries to different folder.

    Whenever I set the breakpoints and start debugger, I see that a test is running but it never hits the breakpoints. If I pause the debugging, I see correct stack trace Clion can’t find appropriate source files. Do I need to change some configuration to help CLion to find all sources?

  29. JulePf says:

    October 4, 2016

    Unfortunately, since 2016.2 using lldb,
    I can only see the first element of arrays in the Variable view. In 2016.1 I could expand the array/pointer variable and it showed the first elements at that address. Makes Clion very uncomfortable for me.

  30. Florian Lyonnet says:

    December 5, 2016

    I am trying to debug a fortran project. I can compile it within CLion IDE however it seems that I am unable to set any breakpoints ? Is that expected?

    F.

    • Anastasia Kazakova says:

      December 6, 2016

      Do you mean a project in Fortran?

  31. Seth King says:

    January 5, 2017

    Anastasia,
    I have remote debugging working but I am unable to step into libraries.
    Is there a way to use “set solib-search-path” from the Clion ide?

    Thanks,
    Seth

  32. coder_girl says:

    January 12, 2017

    I keep getting
    How can I ensure that it’s built with the proper debug options?

    • Anastasia Kazakova says:

      January 12, 2017

      When the build is run the actual cmake command is printed to messages tool window. You can check it there. As well as the rest of the build output.

  33. Jens Eggers says:

    February 2, 2017

    Are there any plans to add breakpoints based on data changes? In MSVC you can set a breakpoint to trigger if a specified memory range is modified.

    • Eldar Abusalimov says:

      February 2, 2017

      Do you mean adding a data breakpoint monitoring an arbitrary memory range, not only some variable/member? Because the latter is already possible using watchpoints.

  34. Julio Jair says:

    April 4, 2017

    Hello, could you help me,
    I just want to know how to turn off the disassembly view..

    • sisi says:

      April 25, 2018

      I also want to know this !Do you know now?Can you tell me?

  35. Fra says:

    April 13, 2017

    Hi,

    is it possible to debug forked processes?

    cheers

  36. anon ymous says:

    September 25, 2017

    Hello,

    This is the 2nd time i use Clion for school projects and i’m very happy with it. Unfortunately,n there is something i don’t understand:
    The first time i used it was on Manjaroo with the latest build. Out of the box the debuger would show me variables & stop at breakpoints.
    Now i am on Fedora 26, still with latest Clion and when i hit ‘debug’ the debuger would stop at any breakpoints & i wouldn’t have any variables in the below frame. I eventually resolved the problem by adding: set(CMAKE_CXX_FLAGS “-g”) after some searching on the web. And i noticed that even tough gdb would stop, all of the breakpoints (even some that i knew couldn’t get hit), were checked with the ‘v’ on it.

    So my questions are:
    – Why did i have to add a cxx flags on fedora and not in manjaroo (if i recall right there was some flags in my CMakeLists.txt)
    – Is my flag right ? Is it no better to do: set(CMAKE_CXX_FLAGS “${CMAKE_CXX_FLAGS -g} ?
    – Why are all the breakpoints checked ? Even impossibles ones ..

    Thank you very much for your time !

    • anon ymous says:

      September 25, 2017

      i mistyped the sentence “Now i am on Fedora 26, still with the latest build and the debuger WOULDNT stop at any breakpoints”.

      Thank you.

    • Eldar Abusalimov says:

      September 26, 2017

      Well, indeed, for the debugger to work, it requires a binary built with debug info, and that’s what -g is for. However, usually you don’t need to specify it by hand as long as you build and run a proper CMake configuration (for instance, Debug or RelWithDebInfo), in that case CMake would add the necessary flag for you.

      As for breakpoints, currently they become “checked” after registering them in the GDB/LLDB, regardless whether they can hit or not. In fact, even breakpoints outside any function would map to the first instruction of some function (usually the nearest one below), so they could hit, in theory.

      Regarding your debugging issues on Fedora, may I ask you to create a ticket in the https://youtrack.jetbrains.com/issues/CPP tracker, with some additional logs collected as described here: https://intellij-support.jetbrains.com/hc/en-us/articles/206560589-Debugger-doesn-t-stop-on-a-breakpoint-Debugger-shows-Command-timed-out-What-to-do-? You will need to reproduce the issue _after_ enabling logging. Thank you!

  37. benjamin moehring says:

    February 22, 2018

    Dear clion team,

    I am trying to debug an imported c++ project. Instead of receiving an exception breakpoint the program quits and shows ‘Process finished with exit code 1’ in the console.

    What could possibly cause the problem? I sent my log files to clion-support at jetbrains.com

    Kind regards,
    Benjamin

    • Anastasia Kazakova says:

      February 23, 2018

      We’ll investigate the logs and will answer you via a support channel.

  38. Matan says:

    March 4, 2018

    When my code crashes, can Clion show me the crashed line of code, like other tools would for say a Java program? can you please let me know?! this is a deal-breaker for me as I’ve wasted lots of time on this during my trial period. Thanks in advance!

    • Anastasia Kazakova says:

      March 4, 2018

      Do you mean a crash on run? Or during the debug session?

  39. Samuel Nelson says:

    October 3, 2018

    So far the debugger and STL containers has not worked for me. I click on the arrow but instead of giving the elements of the set (or map) the arrow disappears and the ui remains the same. Is anyone else having this problem?

    • Anastasia Kazakova says:

      October 3, 2018

      Could you please specify the OS, the debugger and the code sample where you see the issue? Thanks

  40. MachaelYin says:

    November 17, 2018

    Hi, I also came across a problem when I was using the debug and watch in Clion. The debugger and watches can’t display the right length of a set and stack, for example, let’s say a set “set iSet” contains 1, 2, 3, 4, 5. However, when I was using the debugger and watches, it says the length of iSet is 0, let alone to check each variable in iSet. Currently, i am on a Mac OX, using the g++ to compile C++ codes. Do you know how can I solve this problem? Thank you.

    • Anastasia Kazakova says:

      November 17, 2018

      Do you use GDB or LLDB?

  41. Gyuhyeon, Lee says:

    December 16, 2018

    Hello, I’m facing a weird bug where whenever I step into the loop using ‘Step Over’, CLion losts track of where the process was, and doesn’t let me continue anymore as the program is paused, and ‘Resume Program’ button is not activated.

    I am currently using –
    MacBook Pro (15-inch, 2016)
    MacOS Mojave Version 10.14.2
    CLion 2018.3.1 Build 183.4588.63(Latest Build)

    Thank you!

  42. John says:

    January 29, 2019

    CLion is performing admirably. However, the console output in debug does not much stdout when running the same program from the command line.

    Here is stdout when I get the following:

    ./test………….. –gtest_output=xml:/home/unix2/………………test.xml
    Running main() from gmock_main.cc
    [==========] Running 4 tests from 1 test case.
    [———-] Global test environment set-up.
    [———-] 4 tests from TEST_….
    [ RUN ] TEST_one
    [ OK ] TEST_one (4 ms)
    [ RUN ] TEST_two
    [ OK ] TEST_two (2 ms)
    [ RUN ] TEST_three
    [ OK ] TEST_three (2 ms)
    [ RUN ] TEST_four
    [ OK ] TEST_four (2 ms)
    [———-] 4 tests from TEST_…. (10 ms total)

    [———-] Global test environment tear-down
    [==========] 4 tests from 1 test case ran. (10 ms total)
    [ PASSED ] 4 tests.
    make[1]: Leaving directory …..

    However, when run from in CLion, I do not see the stdout. I only see

    Testing started at 5:16 PM …
    /home/unix2/…./cmake-build-debug/… –gtest_filter=* –gtest_color=no
    Running main() from gmock_main.cc

    Process finished with exit code 0

    [… replace filepaths]

    Why does the debug console not show the full stdout output and how can I retrieve that?

    Thank you!!

    • Anastasia Kazakova says:

      January 29, 2019

      Are you running a Google Test Run configuration in CLion?

      • Anastasia Kazakova says:

        January 29, 2019

        You can run Google tests from the IDE, CLion detects them and provides built-in results viewer.

    • Anastasia Kazakova says:

      January 29, 2019

      If you still want to run tests w/o CLion’s Google Test integration, please provide the details at https://youtrack.jetbrains.com/issues/CPP for us to investigate. Maybe some screenshots or a short screencast can be added to get into the details better.

  43. Tómas Þorsteinsson says:

    March 18, 2019

    I cannot seem to make exception breakpoints work in remote debugging. Any known issues with this

  44. Tómas Þorsteinsson says:

    March 19, 2019

    Full remote as described here
    https://blog.jetbrains.com/clion/2018/11/clion-2018-3-remote-dev-cpu-profilers-cpp17/#remote_development

  45. sasha migdal says:

    April 2, 2019

    I am running big applications in Python in PyCharm and I am calling shared libraries in c++. So, my C++ code cannot be called and debugged in CLion as a standalone program. I was using Visual Studio Code where I could configure python script to run my process, then the c++ debugger gets attached to this process so I can place breakpoints in C++ code and debug them.
    Can I do similar things with CLion: run a python process and set CLion breakpoint in a library c++ function?

    • Eldar Abusalimov says:

      April 2, 2019

      Not out of the box unfortunately. You can run a python process and then attach to it using GDB/LLDB from CLion in order to debug your native extension.

Latest Tweets

Related posts

CLion Demo Recording: Because C++ Can Be Competitive

As International Collegiate Programming Contest (ICPC) sponsors and continuous supporters of many educational initiatives, JetBrains thoroughly enjoyed the opportunity to run JetBrains Knowledge Day 2020 last week. This was a unique educational event to mark the beginning of the ICPC competitive season and academic year. Phil Nash, JetBrains C++ Tools developer advocate, gave a talk on using CLion since C++ is widely used in both competitive programming and education. This talk introduces some of the CLion features that can supercharge your coding. It covers completions, including smart comple
by Anastasia Kazakova

CLion Debugging – Part 1: Fundamentals

An important part of writing code is debugging. Despite the name this is not limited to just finding bugs in our code, but can help us to understand what the code is actually doing at runtime - often in a specific environment. While it's possible to do this to some extent using, so-called, "printf-debugging" (inserting code to write out messages and values to the console or a log file), that process is tedious, time-consuming, and very limited. Using a debugger well can make an order of magnitude difference in productivity at this stage - so it would be a shame not to learn our debugging tools
by Phil Nash
Subscribe

Subscribe for updates