Debugger timeout


I am not able to debug any programms in CLion, even with the simple CLion standard "Hello, World" starter program.
I just get a "Command time out" message.

I can compile and run programms without a problem.
I have tried with a newer version of GDB (7.9) and with the built in version (7.8).

I'm on OSX 10.10.3 with CLion v 1.0.3

on Ubuntu same project configuration works without a problem.

Thanks in advance for any help.


I have the exact same problem. Also on 1.03 and OSX 10.10.3 and JRE 1.6


I'm bumping this issue because I really need the debugger working.

Is there any addition information I could provide in order to help pinpoint the problem?


Hi Alexander.

We are working on improvements right now.
We have an issue probably related to your case in the tracker:
We are looking at this problem constantly and thinking about the solution, hope it will be fixed soon.

Could you please add the following lines to (Help | Configure Debug Log Settings)

and attach the idea.log file (Help | Show log in finder) in comments under the issue after the problem will happen again?


Thanks for the feedback. I have posted my configuration and log file on the youtrack issues.


my impression is that either they dont have the manpower or the skills to seriously tackle the debuger task, or sales have not reached the level where they want to invest more into the product. As far as my experience goes, advertising the product today as containing a debugger would be considered unlawful in most european countries.


Hello Christian,

I understand your frustration. I must say though that I am a very happy Jetbrains customer. I use PyCharm for Django/Python developement, as well as PhpStorm for other web projects.
The rate at which JetBrains releases updates and fixes is incredible.

You can see the progress of this bug here on the youtrack issue tracker

Moments ago the Kanban State moved from Review to Ready to Test.
That probably means an update for this is coming soon.

Best Regards,


Hello Alexander,

> I understand your frustration.

I really think you dont. You obviously care for Py- and other Charms the Jetbrains people are entertaining you with, while I only want a working C++ IDE. What I find quite obnoxiuous is the mentioning of "improvements" in a post further above. The're not improving, they are (hopefully) mending fundamental malfunction.



as expected.. already almost 2 weeks, and nothing new. I don't care what their "Kanban" says, looking at the debugger as it is today, I must again voice my doubt whether it will be usable anytime soon. In the meantime they're holding webinars on "Modern C++". Chuckle..


Hi Christian.

Thank you for your patience.
1.0.4 Clion is available now! It contains the fix which was mentioned above.
Please try to use it, does that help?


Hello Anna,

my initial test showed that the this pointer still cannot be inspected, as well as other context variables. That is totally indispensable functionality, as I mentioned elsewhere. Apart from that, value updates still seem suspiciously slow, I can see the "collecting data.." reappear on every step. I will try the debugger every once in a while from now on, and report if the timeout reappears. It is still not usable as my everyday debugger.



after a few tries I can say that I haven't seen the timeout error appear. However, the debugger is so slow that it really isn't fun at all..


Hi Christian.

Sorry for the inconvenience.
We are planning to improve debugger performance problems soon.
We have an issue about slow debugging:

Could you please add some comments about problems and your OS to that issue?
Maybe you can share your project to reproduce the problem?



I'll add some comments. However, I am not sure if I can add anything new. With regard to the project: not worth it. As I already suggested elswhere: just pull some large Open Source project with a well maintained build system (./configure, make, make install) and go from there. Actually, I assume your debugger people aren already doing just that



Hi Anna,

I'm having the same issue as the original poster using Clion 1.0.4 on Ubuntu 14.04. I'm attempting to debug the default "Hello, World!" project created from the New Project dialogue, i.e.

#include <iostream>

using namespace std;

int main() {
    cout << "Hello, World!" << endl;
    return 0;

with no breakpoints, and I get the attached logfile. I'm using the bundled CMake 3.2.2 and GDB 7.8 as my toolchain settings, but I've also tried GDB 7.9 with no success.

Thanks for your help!


Hi Edward.

I've tried to reproduce your problem, but it correctly works for me.
I've added your log and some comments to the issue.
Feel free to comment. Also please subscribe.


just to keep this issue on the table, and to comment on your optimism: now, 1 1/2 months later, the debugger is still a joke - not usable at all. Theres a lot of nice features on Clion (inherited from Idea), but this one just cannot be ignored as long as the product is marketed as an IDE. It seems to be ignored by The Jetbrains people, however. They are putting out new releases and even a EAP for the next version, but no mentioning of the debugger..


Hi Christian,

We are working constantly on the debugger improvements. The latest public updates included:
- Command timed out fix in 1.0.4 update
- LLDB on OS X integration in 1.1 EAP

More issues are currently in development. Others, that are still not, are tracked and analysed by us and we keep an eye on them and will fix them as soon as we can.

Thank you for your patience.


By the way, in case you still meet the debugger timed out problem, please, collect debug logs (Help | Configure Debug Log | Add #com.jetbrains.cidr.execution.debugger) with command timed out and send to us (logs can be found in Help | Show Log) or add to the corresponding ticket. This can help us a lot in the investigation, thanks.


anastasia.kazakova wrote:

By the way, in case you still meet the debugger timed out problem, please, collect debug logs

I certainly won't meet the timeout because I am not using the debugger. It is just too slow, and I cannot inspect the context variables (most notably, the "this" pointer). Its another debugger (QtCreator) for me, as for some of the commentors of the bug you pointed to earlier


Hello Alexander,

time to challenge your confidence in Jetbrains a little more. It has been almost 3 months now since you stated your optimism regarding the debugger issues. There has been no real improvement since. Even the bug report you pointed to, although it has been closed as "fixed", is still not completely solved, as you can see from the comments. And there are other reports that basically address the same issue, like CPP-2920 which are still open. To quote a comment from that report: "The debugger is unusable for serious work (and the performance is the smallest issue)".

It seems obvious that Jetbrains are not able to handle the debugger at this time. They have other priorities, and possibly lack the skills. Understandable - but I'd like to hear them adnmit that.



Hi Christian.

Now we are working on CPP-3627 which is necessary for CPP-2920 and also relates to CPP-1403. Hope it will be fixed soon, because it is in the Develop state.
Also we've implemented LLDB for OS X users.
We are currently working hard and debugger is our top priority for now, among others. So more to come soon.


The same happens to me on Windows/MinGW64. Appears, I cannot debug any more complex then "Hello World", the rest fails with timeout after "Collecting data...". I tried to find good standalone gui frontend for gdb debugger, but so far only VisualGDB worked nicely (it costs though and requires Visual Studio) :(. Alternatives anyone?


here it is again, now on CLion 1.1.1: Debugger timeout every time when hitting the first breaklpoint on a not really complex program under Linux 64bit. A look into the task manager shows a zombie gdb process for every attempt. The zombie processes use lots of CPU.

greetings to the maintainer of the debugger integration.


Agree, so far it is a good C++ editor, but not C++ IDE. For debugger, it is taking too much time for them to resolve and I already got good workaround: (1) added CodeLite as external program, (2) edit and build in CLion (3) switch to CodeLite and use Quick Debug to debug executable generated from CLion (all supported, breakpoints, locals).


Hello Andriy,

I am trying your workaround - maybe you could help me?

My host development is on a Mac. I use an Arm cross compiler toolchain: /ust/local/gcc-arm-none-eabi-4_9-2015q2.

I have the program compiled with debug symbols up and running on the board attached to my USB connection.

I would like to use CLion/CodeLite to debug.

What are the steps I need to take?
I succeed in starting up a debugger server session:

jlinkgdbserver -device nrf51822 -if
swd -speed 4000 -noir -port 2331

and can connect to it using

How did you get this config to work with CLion/CodeLite in order to benefit from step debugging using the UI?

Many thanks!

Sorry for confusion, but this workaround is not to debug in CLion (GUI debugger support in CLion is simply not finished, and crashes with "timeout" most of the time in my case). The workaround is to use external debugger (CodeLite) instead on Windows.  So, I edit and build in CLion, but debug in CodeLite.


No need to be soory, the confusion was on my behalf. I also get timeout when trying to connect. JetBrains just confirmed that they do not support cross-compilers for the moment and I voted to have that in their backlog.
Thanks Andriy!


Just tested clion-143.869.7 with hope debugger is now working... Nope... :(


Looks like it's still happening in CLion 2016.1.2 in Ubuntu 15.10, gdb 7.10 . I can't debug at all. Anyone have a workaround for this yet that doesn't involve debugging in another IDE ?


Dear all,

Currently we are preparing big changes in the debugger that should solve many issues. These changes will be delivered with one of the upcoming EAP builds. Please, follow the updates in our blog:

We'll be grateful if you check the debugger on your projects, when the build is available, and let us know if the problems still occur.