Blog Blog
Home
Home/CLion/More power to debug: Attach to local process

More power to debug: Attach to local process

Anastasia Kazakova

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:
attach_to_local_process_menu
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):
attach_full_list

To simplify the search, just start typing either the name of the process:
attach_search_name
or its pid:
attach_search_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.
debugger_variables

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

#1.5 #2016.1 #Debug #EAP
Comments below can no longer be edited.

30 Responses to More power to debug: Attach to local process

  1. Thomas Watt says:

    January 24, 2016

    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.

    • Anastasia Kazakova says:

      January 24, 2016

      Many thanks for describing the use case. We’ll keep it in mind!

      • Landon Cox says:

        March 31, 2016

        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.

        • Anastasia Kazakova says:

          March 31, 2016

          Stay tuned. We do plan attach to remote process for 2016.2

        • Torbjørn says:

          June 28, 2016

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

  2. Eugene says:

    January 29, 2016

    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.

    • Anastasia Kazakova says:

      January 29, 2016

      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?

      • Eugene says:

        March 21, 2017

        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.

        • Eldar Abusalimov says:

          March 23, 2017

          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?

  3. Pavel Odintsov says:

    March 5, 2016

    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 🙂

    • Anastasia Kazakova says:

      March 6, 2016

      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.

  4. Eugene says:

    March 21, 2017

    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

  5. Jan Schauta says:

    March 20, 2018

    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.

    • Anastasia Kazakova says:

      March 20, 2018

      Interesting idea. Thanks

  6. Danilo Silva says:

    December 21, 2018

    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!

    • Anastasia Kazakova says:

      December 21, 2018

      Am I right that you debug your C++ code and would like to jump to the Python code during debug automatically?

      • Danilo Silva says:

        December 21, 2018

        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.

        • Anastasia Kazakova says:

          December 21, 2018

          Yes, this requires a cross-language debugger which is currently under development. So some time in future you can expect it in CLion.

  7. Danilo Silva says:

    December 21, 2018

    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.

    • Anastasia Kazakova says:

      December 24, 2018

      Ok, thanks for the suggestion. Where and how do you want to see this marker?

      • Danilo Silva says:

        January 9, 2019

        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.

        • Anastasia Kazakova says:

          January 10, 2019

          Ok, got the use case, we need to think about it. Not sure we can easily detect the origin of the system processes.

          • Danilo Silva says:

            January 10, 2019

            Thank you very much in advance

        • Anastasia Kazakova says:

          January 10, 2019

          You can follow this request: https://youtrack.jetbrains.com/issue/CPP-15098

  8. Stefan says:

    March 5, 2020

    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.

Latest Tweets

Related posts

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

Debugging in CLion 2020.3: Set Execution Point

CLion comes with powerful debugger integration, giving you access to backend debuggers such as GDB and LLDB via a uniform UI. The IDE helps you debug efficiently with its built-in variables view, a variety of stepping and breakpoints options, evaluation of expressions, and memory and assembler views. With CLion 2020.3 EAP, we’ve added a new powerful option to control the execution flow during debugging – Set Execution Point. You might be aware of this feature if you’ve ever used Set Next Statement in Visual Studio or Jump to Line in IntelliJ IDEA. In brief, it allows you to move the execution
by Anastasia Kazakova
Subscribe

Subscribe for updates