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.
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
trywith athrowblock now goes to the correspondingcatchblock). - 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:
- Other fixes:
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.
Your CLion Team
JetBrains
The Drive to Develop
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
It is the same, but there might be rendering differences on various platforms. Please report to a tracker.
Debugging is still broken on MacOs with upstream Clang 8.0.1 from brew.
What debugger is that, I guess LLDB? Which macOS version is there for you? And what does “broken” exactly means? What are the errors?
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.
Yes, with Catalina the issue is know. We are working on the fix now. Here is the full list of issues on Catalina we are aware of:
https://youtrack.jetbrains.com/issue/CPP-17126
https://youtrack.jetbrains.com/issue/CPP-14546
https://youtrack.jetbrains.com/issue/CPP-17064
Mind, however, until Catalina is officially released, CLion doesn’t provide official support as well. We are definitely working now to eliminate existing issues, but there might be more.
That is what I figured and why I downgraded to Mojave again. Thanks for the explanation, I love the IDE
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
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
When I say it never stops I mean it never breaks, it just exits the debugged program.
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.
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.
If you have a stable sample/setup to reproduce, may I ask you to collect the debugger log as described here: https://intellij-support.jetbrains.com/hc/en-us/articles/206560589-What-to-do-if-debugger-doesn-t-work-as-expected- and share the logs in the issue (https://youtrack.jetbrains.com/issues/CPP) with us?
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?
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.
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!
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 allide.ssh.library.backend.*.use.sshjpropeties.