More power to debug: Attach to local process

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

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

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

  1. Thomas Watt says:

    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:

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

      • Landon Cox says:

        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:

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

        • Torbjørn says:

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

    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:

      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:

        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:

          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:

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

  4. Eugene says:

    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:

    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.

  6. Danilo Silva says:

    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:

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

      • Danilo Silva says:

        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:

          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:

    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.

Leave a Reply

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