Debugging in CLion

Posted on May 8, 2015 by 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:

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:

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! ■

This entry was posted in Tips'n'Tricks and tagged . Bookmark the permalink.

144 Responses to Debugging in CLion

  1. mwb says:
    May 8, 2015 at 6:27 pm

    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).

    Reply
  2. Christian Sell says:
    May 11, 2015 at 1:58 pm

    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)

    Reply
  3. Karel says:
    June 6, 2015 at 3:48 pm

    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.

    Reply
  4. Serge says:
    June 10, 2015 at 2:48 pm

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

    Reply
  5. rapha says:
    June 11, 2015 at 11:57 am

    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 ?

    Reply
  6. Dan says:
    June 14, 2015 at 4:00 pm

    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?

    Reply
    • Anastasia Kazakova says:
      June 15, 2015 at 5:01 pm

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

      Reply
      • Daniel Colceag says:
        September 26, 2017 at 3:08 pm

        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

        Reply
        • Eldar Abusalimov says:
          September 26, 2017 at 3:44 pm

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

          Reply
          • Luis says:
            May 14, 2018 at 4:22 pm

            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.

  7. Peter Kolski says:
    June 15, 2015 at 3:01 pm

    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!

    Reply
  8. Mayra Albuquerque says:
    August 16, 2015 at 2:59 pm

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

    Reply
    • Anastasia Kazakova says:
      August 16, 2015 at 5:13 pm

      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?

      Reply
  9. Paul Kramme says:
    August 21, 2015 at 9:12 am

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

    Reply
    • Anastasia Kazakova says:
      August 24, 2015 at 9:55 am

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

      Reply
      • Artyom says:
        February 22, 2016 at 3:57 pm

        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.

        Reply
      • Viktor says:
        April 7, 2016 at 5:25 am

        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.

        Reply
        • Anastasia Kazakova says:
          April 7, 2016 at 7:24 am

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

          Reply
          • Viktor says:
            April 9, 2016 at 11:04 am

            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 at 11:09 am

            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 at 2:39 pm

            ok, thanks for the update

  10. czheji says:
    August 21, 2015 at 10:18 am

    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

    Reply
  11. Alexey Ushakov says:
    August 24, 2015 at 8:26 am

    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

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

    Reply
  12. Benjamin Golinvaux says:
    August 28, 2015 at 11:23 am

    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)

    Reply
  13. Igor Tkachuk says:
    September 22, 2015 at 7:57 pm

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

    Reply
  15. dibus says:
    October 22, 2015 at 11:47 pm

    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,

    Reply
    • Anastasia Kazakova says:
      October 23, 2015 at 8:10 am

      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?

      Reply
      • dibus says:
        October 23, 2015 at 12:47 pm

        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”

        Reply
        • dibus says:
          October 23, 2015 at 12:56 pm

          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.

          Reply
  16. dibus says:
    October 23, 2015 at 2:45 pm

    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: .

    Reply
    • Anastasia Kazakova says:
      October 26, 2015 at 8:05 am

      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

      Reply
      • Jared says:
        March 14, 2016 at 12:37 pm

        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?

        Reply
        • Anastasia Kazakova says:
          March 14, 2016 at 3:23 pm

          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.

          Reply
          • Dan says:
            March 23, 2018 at 9:32 pm

            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 at 3:50 pm

    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?

    Reply
    • Anastasia Kazakova says:
      December 2, 2015 at 4:47 pm

      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.

      Reply
      • Thomas Schulz says:
        December 18, 2015 at 11:27 am

        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.

        Reply
    • Anastasia Kazakova says:
      June 9, 2016 at 1:57 pm

      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.

      Reply
  18. Marchorse says:
    December 31, 2015 at 11:17 am

    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?

    Reply
  19. Wes Moncrief says:
    February 12, 2016 at 12:13 pm

    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?

    Reply
  20. Danny Suen says:
    March 25, 2016 at 2:03 pm

    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.

    Reply
  21. Vipin Olikara says:
    April 14, 2016 at 8:18 am

    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.

    Reply
  22. Nickname says:
    April 23, 2016 at 1:50 pm

    During startup program exited with code 127.

    Process finished with exit code 0

    Reply
  23. Andrew Bruce says:
    June 19, 2016 at 1:17 am

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

    Reply
  24. Denis Medvedev says:
    July 19, 2016 at 10:55 am

    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.

    Reply
  25. Oran Shuster says:
    September 15, 2016 at 12:12 pm

    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?

    Reply
    • Anastasia Kazakova says:
      September 15, 2016 at 12:49 pm

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

      Reply
  26. Roger says:
    September 20, 2016 at 7:58 pm

    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?

    Reply
  27. jecyhw says:
    September 21, 2016 at 2:16 am

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

    Reply
  28. Alex says:
    September 23, 2016 at 8:20 am

    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?

    Reply
  29. JulePf says:
    October 4, 2016 at 4:57 pm

    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.

    Reply
  30. Florian Lyonnet says:
    December 5, 2016 at 8:27 pm

    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.

    Reply
  31. Seth King says:
    January 5, 2017 at 6:16 pm

    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

    Reply
  32. coder_girl says:
    January 12, 2017 at 9:21 pm

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

    Reply
    • Anastasia Kazakova says:
      January 12, 2017 at 9:51 pm

      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.

      Reply
  33. Jens Eggers says:
    February 2, 2017 at 7:09 am

    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.

    Reply
    • Eldar Abusalimov says:
      February 2, 2017 at 9:47 am

      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.

      Reply
  34. Julio Jair says:
    April 4, 2017 at 6:43 am

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

    Reply
  35. Fra says:
    April 13, 2017 at 8:16 pm

    Hi,

    is it possible to debug forked processes?

    cheers

    Reply
  36. anon ymous says:
    September 25, 2017 at 8:14 pm

    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 !

    Reply
  37. benjamin moehring says:
    February 22, 2018 at 5:53 pm

    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

    Reply
  38. Matan says:
    March 4, 2018 at 4:38 am

    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!

    Reply
  39. Samuel Nelson says:
    October 3, 2018 at 4:56 am

    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?

    Reply
  40. MachaelYin says:
    November 17, 2018 at 5:08 am

    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.

    Reply
  41. Gyuhyeon, Lee says:
    December 16, 2018 at 5:18 am

    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!

    Reply
  42. John says:
    January 29, 2019 at 12:27 am

    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!!

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *