Blog Blog
Home
Home/CLion/CLion 2019.2.1 Bug-fix Update

CLion 2019.2.1 Bug-fix Update

Posted on by Anastasia Kazakova

Hi,

CLion 2019.2 was released just a few weeks ago, and now we are ready to give you the first bug-fix update. CLion 2019.2.1 (build 192.6262.62) is now available for download from our website, via the Toolbox App, or via snap (for Ubuntu). A patch update will be available shortly. If you haven’t updated to v2019.2 yet, now’s a good time to do so.

DOWNLOAD CLION

This update brings important fixes in several areas.

Fixes in the experimental debugger for MSVC

CLion v2019.2 introduced an experimental debugger for the Microsoft Visual C++ toolchain. Being experimental, it was launched with a list of known issues and limitations. In this update, we’ve fixed some of them:

  • Fixes for the callstacks:
    • Full support for call stacks on x64 systems, including information from exception handling tables.
    • Fixed function representation in call stack.
  • Fixes for stepping:
    • Support for Force Step into, which gets you into the Disassembly View (if the source code is not available).
    • Step over call from within the recursive function now works.
    • Stepping through exceptions now works (Step over call from within try with a throw block now goes to the corresponding catch block).
    • Performance improvements for stepping when variables are muted.
  • Fixes for threads:
    • Threads’ names in the list of threads are now available.
    • Threads are sorted by created time.
  • Fixes in rendering:
    • Fixed issues with rendering STL types (all containers from CPP-16661 now work).
    • Custom NatVis in STL container is now working (CPP-16675).
    • Custom NatVis loaded from the outside of the project directory is now working (CPP-16676).
  • Other fixes:
    • Watchpoints are now working (CPP-14936).
    • Exception breakpoints are now working (CPP-14564).

Other C++-related improvements

Unfortunately, in v2019.2 several inspection settings were not imported correctly when upgrading from 2019.1. This is now fixed.

We’ve also fixed a freeze on Go to Declaration (CPP-13969).

JBR update

With this bug-fix update, we have also updated both JetBrains Runtime 11 and JetBrains Runtime 8, on which CLion and other IntelliJ-based IDEs are built. The fixes covered the broken rendering of Fira Code fonts, IDE-managed HiDPI mode on Windows, the issue with the Ctrl+C shortcut in the integrated terminal on macOS, and a crash when WebView is used on RHEL Linux 7.3. For more details, see this blog post.

Find the full release notes here. Want to know what’s next? See our roadmap for CLion 2019.3.

DOWNLOAD CLION

Your CLion Team
JetBrains
The Drive to Develop

#2019.2 #Debug #MSVC #newsletter-cpp
Comments below can no longer be edited.

17 Responses to CLion 2019.2.1 Bug-fix Update

  1. Taw says:

    August 22, 2019

    Hi Anastasia, I have a question please, I don’t know where to ask: why some fonts (like Consolas) are rendered so beautiful on Linux and so ugly on Windows?Don’t you use the same internal java runtime? thanks

    • Anastasia Kazakova says:

      August 22, 2019

      It is the same, but there might be rendering differences on various platforms. Please report to a tracker.

  2. Conrad Jones says:

    August 23, 2019

    Debugging is still broken on MacOs with upstream Clang 8.0.1 from brew.

    • Anastasia Kazakova says:

      August 23, 2019

      What debugger is that, I guess LLDB? Which macOS version is there for you? And what does “broken” exactly means? What are the errors?

      • Mèir says:

        August 23, 2019

        I had this same problem when running macOS Catalina Developer Beta 5 (Haven’t tried the newest beta that launched this week). I reverted back to Mojave because of this problem. It is ‘broken’ as follows: You press the debug button, CLion prepares the debugging view and waits for LLDB to load but the problem is that LLDB never loads. If you look in Activity Monitor you can see that LLDBFrontend keeps 1 CPU thread at 100% and CLion keeps waiting for LLDB and nothing happens.

      • Conrad Jones says:

        August 23, 2019

        LLDB, MacOS Mojave 10.14.6 ( current Production Version )

        broken meaning, the process being debugged just ends. I have 2019.1.4 installed also, this does not crash. I believe it’s something do with the inspection of variables and their values.

        Clang from homebrew

        clang version 8.0.1 (tags/RELEASE_801/final)
        Target: x86_64-apple-darwin18.7.0
        Thread model: posix
        InstalledDir: /usr/local/Cellar/llvm/8.0.1/bin

        ~ uname -a
        Darwin *HOSTNAME* 18.7.0 Darwin Kernel Version 18.7.0: Thu Jun 20 18:42:21 PDT 2019; root:xnu-4903.270.47~4/RELEASE_X86_64 x86_64

      • Conrad Jones says:

        August 23, 2019

        This is enough to Repro it for me:

        https://github.com/conradjones/ClionDebugTest

        put a breakpoint where indicated by the comment, it never stops and just prints this to the console (hello world is never printed), Clion 2019.1 will break at that point.

        Process finished with exit code 0

        • Conrad Jones says:

          August 23, 2019

          When I say it never stops I mean it never breaks, it just exits the debugged program.

          • Maria Baburina says:

            August 24, 2019

            Hi, Conrad! Thanks for reporting the issue. I tried to reproduce it on the same setup (macOS 10.14.6, clang-8.0.1) using your project but in my case, LLDB hits breakpoint as expected.
            Can I ask you to create a ticket https://youtrack.jetbrains.com/issues/CPP so we could proceed with the investigation? Could you also enable debug logging by entering #com.jetbrains.cidr.execution.debugger into Help | Configure Debug Log Settings, restart the IDE, reproduce the problem and attach the idea.log file (Help | Show Log) to the ticket?
            Please note that the log might contain private information, ticket’s visibility can be restricted to CLion team.

          • Matt Hurd says:

            August 27, 2019

            Conrad, I get a similar thing FWIW – going to hover over a bool on a breakpoint and it silently exits the debugger and program for no real reason but has worked on other vars and at other breakpoints in the code.

            This Clion release with JBR8 jre on Linux (Ubuntu 18.04 LTS) clang 8.0.1 and bundled lldb 7.0.1

            It works fine with the bundled gdb and clang 8.0.1

            External lldb-8 doesn’t work at all (“Command timed out”).

            This does not seem specific to this clion release. I’ve had a few issues over time with lldb and clion and generally just used gdb. Also, I’ve had a few issues with lldb over time outside of clion so I’m a little wary of lldb in general.

  3. antidotcb says:

    August 23, 2019

    If I set a custom clang-tidy binary path, I lose all clang-tidy inspections in IDE. Is it by design?
    Does built-in clang-tidy respects .clang-tidy configuration placed 8n project root directory?

    • Anastasia Kazakova says:

      August 23, 2019

      It shouldn’t be so, if that’s Clang-Tidy inspections present in the binary you point to. Please report a ticket to the tracker with IDE log and IDe and custom binary versions.

      CLion can use the .clang-tidy configuration file, switch to it in settings: Settings/Preferences | Editor | Inspections | C/C++ | General | Clang-Tidy. By default CLion uses IDE settings, skipping the .clang-tidy config.

  4. Paolo says:

    August 27, 2019

    After upgrading to 2019.2.1 from 2019.2, I am not able to connect to my docker container or to any remote hosts via ssh (Build,Execution,Deployment -> Toolchains – > Credentials).
    This was working before. My machine: KUbuntu 19.04
    Logs:

    2019-08-27 09:06:04,908 [ 244571] WARN – om.intellij.ssh.impl.sshj.sshj – Unsupported options in config: [HashKnownHosts=no, compression.s2c=zlib,none]
    2019-08-27 09:06:04,928 [ 244591] WARN – ort.IdentificationStringParser – Server identification has bad line ending, was expecting a ‘\r\n’ however got: ‘4’ (hex: 34)
    2019-08-27 09:06:04,929 [ 244592] WARN – ort.IdentificationStringParser – Will treat the identification of this server ‘SSH-2.0-OpenSSH_7.4’ leniently
    2019-08-27 09:06:04,988 [ 244651] WARN – net.schmizz.concurrent.Promise – <> woke to: net.schmizz.sshj.userauth.UserAuthException: Exception during context initialization
    2019-08-27 09:06:04,988 [ 244651] WARN – om.intellij.ssh.impl.sshj.sshj – Failed to connect. Brief info: SSHJ connection to root@:22
    compressionFactories from config: none, with signatureFactories: ssh-rsa, ssh-dss, ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, ecdsa-sha2-nistp521, ssh-ed25519, with keep alive interval 120 seconds, with keep alive count max 3, with com.intellij.ssh.OpenSshLikeHostKeyVerifier(knownHostsFile=[/ho], strictHostKeyChecking=NO), with identity {/ho{,.pub}, without passphrase}, with authentications: publickey by PlatformAuthPublickey, password by AuthPassword, keyboard-interactive by AuthKeyboardInteractive, with connect timeout 5000, with kerberos
    Connected
    => none by net.schmizz.sshj.userauth.method.AuthNone@274b9aa1 (failure, new allowed auth methods: publickey, gssapi-keyex, gssapi-with-mic, password)
    => gssapi-with-mic by net.schmizz.sshj.userauth.method.AuthGssApiWithMic@4f00d7df (
    net.schmizz.sshj.userauth.UserAuthException: Exception during context initialization
    at net.schmizz.sshj.userauth.method.AuthGssApiWithMic.handleContextInitialization(AuthGssApiWithMic.java:128)
    at net.schmizz.sshj.userauth.method.AuthGssApiWithMic.handle(AuthGssApiWithMic.java:176)
    at net.schmizz.sshj.userauth.UserAuthImpl.handle(UserAuthImpl.java:142)
    at net.schmizz.sshj.transport.TransportImpl.handle(TransportImpl.java:500)
    at net.schmizz.sshj.transport.Decoder.decodeMte(Decoder.java:159)
    at net.schmizz.sshj.transport.Decoder.decode(Decoder.java:79)
    at net.schmizz.sshj.transport.Decoder.received(Decoder.java:231)
    at net.schmizz.sshj.transport.Reader.run(Reader.java:59)
    Caused by: java.security.PrivilegedActionException: GSSException: Invalid name provided (Mechanism level: KrbException: Cannot locate default realm)
    at java.base/java.security.AccessController.doPrivileged(Native Method)
    at java.base/javax.security.auth.Subject.doAs(Subject.java:423)
    at net.schmizz.sshj.userauth.method.AuthGssApiWithMic.handleContextInitialization(AuthGssApiWithMic.java:126)
    … 7 more

    Any suggestion?
    Thanks!

    • Vasily Romanikhin says:

      September 2, 2019

      Hello,

      In 2019.2 we enabled new SSH backend. It seems it’s a reason of your problem.
      I’ve created a proper ticket https://youtrack.jetbrains.com/issue/PY-37790, please follow that, possibly we will ask additional details in comments.

      Also as temporarily solution you can switch back to old version of ssh module:
      Help -> Find Action -> type "Registry" and disable all ide.ssh.library.backend.*.use.sshj propeties.

Latest Tweets

Related posts

Aiming for more! CLion 2020.3 Roadmap

CLion has just been given a massive update from 2020.2, with Makefile project support, more C++20 features supported, new code analysis checks, Doctest framework integration, and much more. We have even more planned for the next release. Let’s take a look at what we have in store for the fall. Special thanks Before we move on to our plans for 2020.3, let’s follow our tradition of thanking everyone who has helped us identify various issues, usability glitches, and missing features during the Early Access Program. Thank you all! Without your contributions we would have never been able to have su
Posted on by Anastasia Kazakova
Subscribe

Subscribe for updates