Hi,
With the recent 1.5 EAP build we’ve announced a new feature called Attach to local process. Let’s take a closer look at it.
In general, you can find the information about debugging in CLion in the corresponding blog post, it also includes a short demo. So in case you are interested in various breakpoints types supported in CLion, built-in debugger UI, ways to evaluate and view variables, please, refer to the post to learn the details. These topics are also covered in our webhelp in details.
Since the first CLion Public Early Access preview build we’ve been getting questions on remote toolchains support, including remote debugging. To make the very first step in that direction we’ve started with attaching to local process functionality. In a nutshell, it allows you to debug processes, run on the same machine as CLion, by attaching to them using their pid or process name.
Currently in CLion attach to local process is available for GDB on Linux and Windows and LLDB on OS X (so not available for GDB on OS X). You can find the corresponding action in the Run menu of the IDE:
or call it via Find Action dialog (Shift+Ctrl+A on Linux/Windows, ⇧⌘A on OS X). All the processes will be listed in the dialog (Rem. Please, mind two problems we are currently aware of here – IDEA-150592 and IDEA-150591):
To simplify the search, just start typing either the name of the process:
or its pid:
Select process to attach with CLion and now you can debug it with all the usual staff available in the IDE, including breakpoints, stepping, variable views, etc.
To detach click the ‘Stop the process’ button in the debugger toolwindow in the IDE (we’ll make the name more accurate in the later builds, since currently it detaches and doesn’t stop the process of course – CPP-5629).
Upd. Find the prerequisites for Ubuntu users in our webhelp.
In the end, let us also share feature requests related to the topic that you can find interesting. Feel free to leave comments, upvote and share your personal use cases (they really help us to figure out the proper implementation and UI, so thank you in advance!):
- Debug forked child processes (CPP-955).
- Debug arbitrary binary (CPP-1313).
- Attach to Existing Process: add re-run button (OC-3352).
- Remote debug (CPP-5539).
That’s it! Download the build and give it a try.
Sincerely yours,
The CLion Team
So close – please keep developing this feature!
Our company is doing remote gdb debugging for ARM embedded development and we would really like to use CLion as the IDE.
We are using the standard gcc toolchain (arm-none-eabi-gcc) and then OpenOCD to open a session to talk to the debug probe connected to the target hardware board. Then using arm-none-eabi-gdb -tui ./target/firmware.elf followed by target remote localhost:3333.
I was hoping with this EAP 1.5 release that we could finally get rid of that ‘-tui’ and use a real IDE for debugging instead of the text ui. Sadly we are mostly on Mac OSX and this release didn’t quite get support for attach to local GDB process on Mac.
Soooo looking forward to trying it.
Many thanks for describing the use case. We’ll keep it in mind!
I have this exact need as well – CLion could take the ARM development market by storm with this feature. Most of the IDEs for ARM (IAR, Eclipse, etc) are substandard comparatively.
Stay tuned. We do plan attach to remote process for 2016.2
+1
Working with a vendor-supplied ZigBee stack, I’m forced to use IAR (TI, I’m looking at you! >.>). Luckily I found a plugin that allows me to work in Eclipse while using the IAR compiler, linker and debugging support, but it’s still not the same as CLion/IntelliJ…
If I could work in CLion (with the same integration), I would switch immediately – Eclipse isn’t even anywhere close to the autocompletion and usability of CLion. Please make it happen!
So when I attach to node process running my c++ module on Mac, my breakpoints never hit. Any ideas? Tried to switch to GDB toolchain: no effect… Can you make up an example of debugging node modules? That would be the most valuable function to CLion.
First, pay attention that attach to local process is not available for GDB on OS X, only with LLDB.
Could you also comment on ‘node process running my c++ module’ – what exactly do you mean? nodejs?
sorry for the confusion, I’m developing c++ code in Linux and using Clion bundled 7.11.1 gdb. I have a service running and I want to attach to it and do debug, it can attach to the process but break point won’t stop.
Apologies for the late response. Is it possible, by chance, that the executable you attach to doesn’t have debug symbols? How exactly do you build a module? Is it just a shared library loaded by node.js at runtime or something else?
Hello, folks!
Thanks for nice job! But actually I could not use Clion because I’m working on Mac OS X but my project need so much Linux staff (kernel modules and ~20 custom linux-only libraries)
So I’m working with remote folder mounted on my dev laptop. But actually I could not find any way to call cmake over ssh instead of local run. I have complete build environment on remote server but I need some way to override build command
Unfortunately, remote work is not supported yet. It should be done within this task: https://youtrack.jetbrains.com/issue/CPP-744 – follow to get the updates or/and leave comments.
Clion cannot stop at break point when attach to running process in Ubuntu14:
I did attach to process but it won’t stop at the break points, any ideas on it? I’m using bundled gdb and it used to work on ubuntu12 but after upgrade to 14 it stops to work. Gdb is correctly attached to the process but breakpoint is not working…
Thanks
Eugene, could you enable debug logging 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-, then reproduce the problem and send the logs collected either through our support channel or anyhow it is convenient for you? We’ll investigate.
It’s 2020 now and I am still having Eugene’s issue in CLion which is stopping me from using CLion as a real “IDE”. Back to good old emacs! Any suggestions to resolve will be hugely appreciated.
Could you please collect logs and described above and share with us?
Great feature!
It would be nice though to add “Attache to local process” template to Run/Debug configurations. To attach process through some pattern.
Then it could be just one Shift+F9 to build->run->attach->debug.
Interesting idea. Thanks
This is feature is very nice. Thanks for that. Is there any chance of having some integration with pytest? I mean, when I’m debugging a test that uses a python binding for C++, I always need to check the python PID from the execution console and then I need to manually attach that. This is very time consuming as we do that all the time and to have something to make this process automatic would be very great.
If you need more details about this workflow (which is very common for scientific stuff), please, let me know. I will be glad to help.
Thank you!
Am I right that you debug your C++ code and would like to jump to the Python code during debug automatically?
Actually, I do the oposite. I run python tests that calls C++ code. I have to set breakpoints on both python and C++, because I need to know python PID before attaching to GDB. I wish I could have a way of jumping to C++ without this trick.
Yes, this requires a cross-language debugger which is currently under development. So some time in future you can expect it in CLion.
Well, I understand that this would be much more robust. But currently, If you at least provide me a marker on processes that were started by clion (in my Case, pytest runner), it would help me a lot.
Ok, thanks for the suggestion. Where and how do you want to see this marker?
Oh, sorry for the delay. Just after you enter “Attach to Process…” they are currently ordered by PID. If you put the python process started by clion at first or at least put it another color (or with some extra label, I don’t know what fits better) that will be enough to skip the process of manually discovering its PID. I currently can filter by the name of the process (python), but generally my system have more than one with same name.
Thank you for replying.
Ok, got the use case, we need to think about it. Not sure we can easily detect the origin of the system processes.
Thank you very much in advance
You can follow this request: https://youtrack.jetbrains.com/issue/CPP-15098
Would it be possible to make CLion’s interactive (gdb-based) debugger to attach to Java processes, which forks other C++ based processes, and hit breakpoints into the C++ code of those child processes?
I find it tedious to have to manually attach to those child C++ processes, and I miss the startup part of the c++ code.
Thank you.