CLion 2019.3 EAP: Debugger Improvements

Hi,

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.

DOWNLOAD CLION 2019.3 EAP

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

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

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
JetBrains
The Drive to Develop

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

29 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 :(

  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 https://youtrack.jetbrains.com/issue/CPP-14177 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.

    • Anastasia Kazakova says:

      Thank you, Richard, we’ll consider how we can help here.

    • Vasily Romanikhin says:

      Hello Richard,

      I’ve added workaround to the ticket description: https://youtrack.jetbrains.com/issue/CPP-14177.

      • Thanks for the workaround description I hope it will help people having this issue. On docker (you can just map the clion install folder on the exact same path as on the host and it works ).

        Never the less ist there a way to use the .gdbinit (now from the project root) and add the /bin/gdb/renderers/* to the project source tree so clion would copy it to the remote automatically. This way we can check in the workaround to the project and every developer would leverage from it on all targets … eliminate the manual work each time ?.

  6. ps says:

    Some kind of bug in this one. Upon start, CPU spikes and stays up there (ui,icons being the hog).
    Even editing a simple text file is impossible, there’s delay of almost a second between typing a key and seeing the character appear on the screen. The issue doesn’t go away.

    Had to downgrade to prev version.

  7. Mike says:

    On every start last two EAPs are showing balloon with “WARN – openapi.keymap.impl.KeymapImpl – Cannot find parent scheme Mac OS X 10.5+ for scheme Xcode”

    This is kind of annoying.

  8. Taw says:

    The debugger is terrible slow in latest EAP, I don’t recall having this problem in latest EAP, the variables take like 1 second to appear compared to 2019.2. Please dont’ release final 2019.3 with this problem.
    The bug is CPP-17701, thanks.

  9. Andrew says:

    It looks like LLDB support is the place to be, even on Linux. I’m doing remote dev from OSX to Aarch64 Linux (Ubuntu 18.04). Is LLDB working for remote debug on Aarch64 yet?

Leave a Reply

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