CLion 2019.3 EAP: Debugger Improvements


A new CLion 2019.3 EAP (build 193.4386.19) is now available! Get it from our website, via the Toolbox App, or as a snap package (if you are using Ubuntu). A patch-update for those using the previous EAP build will be available shortly.


In this quality-targeted release, we work a lot on polishing CLion’s support for debuggers. As you know, we support two back-ends, LLDB and GDB. This build brings some long-awaited improvements and fixes for both.

LLDB: better pretty printers are in use

In the previous EAP build, we updated the bundled LLDB on macOS and Linux to v9.0. Now, we’ve cleaned the incorrectly working pretty printers for LLDB, fixing a whole set of related issues, which you can find linked to the parent ticket CPP-17548.

From the tables below, you can see that on macOS, libc++ is handled much better than libstdcxx for now:

On Ubuntu, there is more of a parity between the two:

GDB: read .gdbinit from the project root

Quite often you need to tune the debugger behavior via passing some commands and options in a .gdbinit file. Previously, CLion always read this file from the user’s home directory, which definitely was not very convenient and could cause conflicts. Now, CLion supports reading the .gdbinit file from the project root directory. This means you can customize your GDB experience on a per-project basis.

Note that to enable this behavior, you have to explicitly allow it in your home .gdbinit file, either globally or for a particular project. For the exact commands, see this.

By the way, a similar feature for LLDB is currently in development as well. Stay tuned!

Improvements from the IntelliJ Platform

There are also more enhancements in CLion coming from the IntelliJ Platform:

  • We’ve updated the Database support bundled into CLion with initial support for MongoDB.
  • We’ve fixed the issue with project opening on macOS 10.15 Catalina (JBR-1721).

Read more details in this blog post.

The full release notes are available here.

Your CLion Team
The Drive to Develop

This entry was posted in Announcement, Early Access Preview and tagged , , , , , , . Bookmark the permalink.

15 Responses to CLion 2019.3 EAP: Debugger Improvements

  1. Roman says:

    Any chance to get better libstdcxx support in this release cycle?

    • Eldar Abusalimov says:

      You mean for LLDB? Or for GDB?

      • Roman says:

        Well, if LLDB will have same features as GDB, it makes no sense to use GDB, since LLDB is faster. But if you can speed-up GDB then, why I need LLDB, since GDB more familiar :)

    • Anastasia Kazakova says:

      Are you talking about macOS? Because there GDB works quite badly and I don’t think we’ll be able to do smth with it soon.

      • Roman Popov says:

        No, I’m talking about Linux.

        • Anastasia Kazakova says:

          Ok, thanks. On Linux I guess LLDB has the only problem with unordered associative containers as mentioned in the table. If that’s crucial, you can work with GDB, which doesn’t have this issue.

          • Roman says:

            Yeah, and I hope that std::any, std::variant and std::optional can be supported in LLDB too. And std::function is not supported anywhere. Added feature proposals to tracker.

  2. Taw says:

    I would really like to see that char* are printed on a single line, like all the other IDEs do. I know that Eldar was kind to say that is not a priority, but with so debugger improvements, it would be nice to have that one also. (CPP-12739). thank.

    • Anastasia Kazakova says:

      That’s true that currently there are more issues/bugs with higher priority. But we’ll check this our again to see if maybe some custom pretty-printer can help.

  3. Piotr Kasprowicz says:

    Any chance to get fix for CPP-12576 in the next build?

    It is a huge showstopper in embedded projects when using non-gcc commercial toolchains :(

    • Anastasia Kazakova says:

      Can you maybe provide more details on the particular problem in your case? The problem with pch-preprocess flag was fixed and we don’t see other complaints in this ticket. Would be good to understand where your issue is coming from.

  4. KGH says:

    Two comments:
    gdb support is very useful with embedded projects. We have gdb server running on the embedded platform and gdb on the development system.

    How is ninja support coming, it really speeds up builds.

  5. I’m using Clion 10 hours a day mostly doing remote development either in dockers or directly on different embedded target we use modern c++ and GDB pretty-printing is a must for us. But there is a nasty bug which makes your default settings of remote debug with remote development not happy.

    Can you at least have a note on the remote debugging guide where people are warned and a step by step guide how to work around the problem at best with this nice new feature of using project root gdb init ( I hope it is downloaded to the target and used there as well in case of remote dev :) ).

    Please keep up the good work and make some effort to improve remote development. (and or add docker native integration ) ( I’m now using docker in a way that I have a container deployment where I start sshd daemon in run cmd and set clion with remote dev toolchain). It works but after cmake generation, the loading takes long …

    And there are glitches in the syncing generated files (created during build steps) back to host. this has an effect on intellicense since generated .hpps / cpps are missing.

    I think remote debugging is one of the unique features of CLion and it makes our development day to day flow much fluent.

Leave a Reply

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