the 5 things I miss most in CLion

Here they are:

1. no working debugger (gcc 4.8.2 on Mint 17 Linux)
2. no working debugger (did I say that already?)
3. no sorting in overview window. Using the overview for navigation in a file with, say, 30 methods is useless. I end up using manual find all the time
4. no full qualification of members in overview for implementation file (cpp). If you have member functions from different classes, you cannot tell them apart
5. no indication about call location in call hierarchy view. You get the methods where the call occurrs, but if its a large method, its Ctrl-F again.

I am a paying customer, but you will hear me swearing at Clion several times per day as a former Eclipse/Java user. It would be so easy to implement some of these features. Getting a functional debugger may be a little harder, but there are people out there that can do it (look at QtCreator).

-Chris

12 comments
Comment actions Permalink

Please, find my comments below:

1. no working debugger (gcc 4.8.2 on Mint 17 Linux)
2. no working debugger (did I say that already?)
Could you provide more details in our tracker: https://youtrack.jetbrains.com/issues/CPP? Are you using a bundled debugger or some other one? Are you able to debug with that particular debugger without CLion? What error CLion shows? Describe, please, what you were doing and what did you get.

3. no sorting in overview window. Using the overview for navigation in a file with, say, 30 methods is useless. I end up using manual find all the time
What do you mean under 'overview window'?
By the way, most all the tool windows in CLion supports the quick search - just start typing what you are looking for:
Screen Shot 2015-05-09 at 19.42.23.png
Also there are Search by class name or symbol name, that can be helpful in terms of navigation.

4. no full qualification of members in overview for implementation file (cpp). If you have member functions from different classes, you cannot tell them apart

Could you please submit to our tracker (https://youtrack.jetbrains.com/issues/CPP) a sample of what kind information and where would you like to find? We'll consider your feature request.


5. no indication about call location in call hierarchy view. You get the methods where the call occurrs, but if its a large method, its Ctrl-F again.
Could you please explain the use case? Anyway you could simply navigate to this call entry from the hierarchy view. Or you can change the scope of the search if you don't what to see all the callers from all classes in your prj. Will this help?

0
Comment actions Permalink

@debugger: I will not enter this into the tracker. You do it if you care. Thank you. The debugger I am talking about is the standard debugger that Clion uses on my platform. I have not reconfigured anything in Clion. QtCreator (the real IDE alongside which I am using Clion for editing purposes) does the same, and works well. I suggest you simply try your debugger integration on all common linux platforms, rather than writing fancy blog entries about the merits of debugging in Clions. I repeat: there is no debugger integration in Clion on Linux Mint 17 with gcc 4.8.2.

@overview window. What I call overview is what you call structure. Sorting is an essential feature if the file is large, particularily if, like me, you dont like having having to type CTRL-F and/or a search term. I want to navigate by looking. Typing is not an alternative

I have already entered most of the stuff into the tracker half a year ago. Nothing happened.

Below an example of the structure view alongside a CPP implementation file. Note that the file contains implementation code for 2 different classes, and standalone functions. However, the method signatures dont show to which class they belong, which makes navigation nearly impossible, particularily if classes have methods of the same name (and signature). Look how other IDEs handle this (QtCreator is a good example). for your convenience, I have included an image of the same view in QtCreator right below

Clion Structure view:
structure.png
QtCreator outline view:
outline.png

@no indication about call location. Also this is already in the tracker for a long time. I'll again illustrate with some screenshots. If you want this in the tracker, go ahead and transfer it.

Clion call hierarchy: note that all I see is that the method GStreamerMediaPlayer::handleSegmentEnd is called 2 times inside method GStreamerMediaPlayer::iSeek. When I click on iSeek, I am placed at the top of the method, which happens to be 500 lines long. There is no way to find the individual call locations, other than typing CTR-F and searching for the method name (going back to paper age tools, so to say)
callhier.png
In Eclipse: the individual call locations are highlighted. Clicking on the "callerTest" line in the Call Hierarchy view repeatedly takes me to the next call location.
eclipsecall.png

0
Comment actions Permalink

christian@gsvitec.com wrote:


@debugger: I will not enter this into the tracker. You do it if you care. Thank you. The debugger I am talking about is the standard debugger that Clion uses on my platform. I have not reconfigured anything in Clion. QtCreator (the real IDE alongside which I am using Clion for editing purposes) does the same, and works well. I suggest you simply try your debugger integration on all common linux platforms, rather than writing fancy blog entries about the merits of debugging in Clions. I repeat: there is no debugger integration in Clion on Linux Mint 17 with gcc 4.8.2.


Of course it's your choice to not open an issue in the tracker.  However, I will let you know that Clion debugging works fine on my Linux Mint 17.1 (Rebecca) with gcc 4.8.2.

0
Comment actions Permalink

mwb1100 schrieb:

However, I will let you know that Clion debugging works fine on my Linux Mint 17.1 (Rebecca) with gcc 4.8.2.

good for you. What I was trying to transmit is 2 things:

1. debugger does not work on my machine, with standard OS install, where other IDEs have no problems. I have 25 years of working with debuggers and IDEs behind me, haven't ever seen one that has such problems, either
2. the phrase "put it in the tracker" (sometimes prefixed with "I dont understand") is so cheap. I have invested enough work already in making this post

0
Comment actions Permalink

I've asked about the tracker only because it's a more convenient way to report/follow problem's progress. But let's continue here, if it's more convenient to you. Could you please show us the Settings | Build, Execution, Deployment | Toolchains page screenshot? As you see, for some users debugger is working successfully on Linux Mint, so let us help and find what's the problem in your case. Hopefully we can solve it.

I agree that showing a class name in File Structure, as well as location in call hierarchy can be useful. Thanks for the explanation and use case. It's more clear now. I've uploaded your screenshots to the tracker.

0
Comment actions Permalink

heres the toolchains page:
toolchains.png
and here the settings:
dbg_settings.png
however, thinking about it twice, I would rather point to the specifics of my application than to the OS (or the above configuration, which is the least likely candidate) for a reason for the malfunction. The application is heavily multithreaded (GStreamer based) and fairly large. Maybe that is what throws Clion off the track.

I just tried it again: the first breakpoint was hit, however stepping was quite slow. After that, breakpoints were not honored any more (even though the code path went by them), and shortly after that the application was terminated, and a "command timeout" message appeared on the console. A second try let me debug for a few minutes with 2 breakpoints, but as soon as I let the application run for a few moments without hitting a breakpoint, it was again terminated. To repeat: the application runs without problems when started outside the debugger, and it can be debugged perfectly with my other IDE.

Beyond that: the impossibility to inspect the "this" pointer alone is a reason to not to use this debugger integration. After all, the "this" pointer (i.e., the state of the object that is executing) is the first and foremost thing you will want to look at

0
Comment actions Permalink

Thanks you very much for the detailed responce and screenshots. Looks like this is the same as: https://youtrack.jetbrains.com/issue/CPP-1403. We are loooking at this problem constantly and thinking about the solution. Still we can't reproduce the problem stable enough that makes it a bit difficult to fix. But it's in our short term roadmap for sure.

0
Comment actions Permalink

I can reproduce it anytime, it really shouldn't be hard for you, either. Just pull some complex open source project (e.g., a GStreamer-based Mediaplayer like Amarok), build it and debug. I am sure you'll hit it soon.

Sorry to say, but as long as these problems exist, I consider the debugger integration non-existent, the product as pre-beta, and the license I bought as a form of crowd-funding.

0
Comment actions Permalink

some more debugger experiences: even on a small (however multithreaded) project, hitting
the pause button causes program and debugger termination.

0
Comment actions Permalink

Christian,
does the problem still happen in CLion 1.0.2?

0
Comment actions Permalink

yes, thats what I am using


0
Comment actions Permalink

Experiencing exactly the same on OSX Yosemite, Clion 1.0.2, embedded gdb.

Application with 4 threads with 2 breakpoints set before running it: first breakpoint hit, second breakpoint hit, then clion becomes slow, doesn't display any of the local variables and breaks out of debugging with a timedout exception as in the following log excerpt.
Gdb process remains alive and must be manually terminated with a kill -9:

2015-05-20 16:45:57,035 [      0]   INFO -        #com.intellij.idea.Main - ------------------------------------------------------ IDE STARTED -----------------
-------------------------------------
2015-05-20 16:45:57,118 [     83]   INFO -        #com.intellij.idea.Main - IDE: CLion (build #CL-141.871.28, 18 May 2015 00:00)
2015-05-20 16:45:57,118 [     83]   INFO -        #com.intellij.idea.Main - OS: Mac OS X (10.10.3, x86_64)
2015-05-20 16:45:57,118 [     83]   INFO -        #com.intellij.idea.Main - JRE: 1.8.0_40-internal-b64 (JetBrains s.r.o)
2015-05-20 16:45:57,118 [     83]   INFO -        #com.intellij.idea.Main - JVM: 25.40-b25 (OpenJDK 64-Bit Server VM)
2015-05-20 16:45:57,126 [     91]   INFO -        #com.intellij.idea.Main - JVM Args: -Dfile.encoding=UTF-8 -XX:+UseConcMarkSweepGC -XX:SoftRefLRUPolicyMSPerMB=
50 -ea -Dsun.io.useCanonCaches=false -Djava.net.preferIPv4Stack=true -Xverify:none -Xbootclasspath/a:../lib/boot.jar -Xss2m -Xms256m -Xmx2000m -XX:MaxPermSize=3
50m -XX:ReservedCodeCacheSize=96m -XX:+UseCompressedOops -Djb.vmOptionsFile=/Applications/CLion.app/Contents/bin/clion.vmoptions -Didea.java.redist=custom-jdk-b
undled -Didea.home.path=/Applications/CLion.app/Contents -Didea.executable=clion -Didea.platform.prefix=CLion -Didea.paths.selector=clion10
2015-05-20 16:45:57,163 [    128]   INFO -        #com.intellij.idea.Main - JNA library loaded (64-bit) in 36 ms
2015-05-20 16:45:57,174 [    139]   INFO -        #com.intellij.idea.Main - initializing environment
.
.
.
2015-05-20 16:48:25,947 [ 148912]   INFO -        #com.jetbrains.cidr.cpp - Building: /Applications/CLion.app/Contents/bin/cmake/bin/cmake --build /Users/abigagli/Library/Caches/clion10/cmake/generated/f8cda5b3/f8cda5b3/Debug --target CP -- -j 4
2015-05-20 16:48:31,537 [ 154502]   INFO - brains.cidr.execution.debugger - Debugger started
2015-05-20 16:49:27,736 [ 210701]   WARN - brains.cidr.execution.debugger - Command timed out
com.jetbrains.cidr.execution.debugger.backend.DBTimedOutException: Command timed out
        at com.jetbrains.cidr.execution.debugger.backend.gdb.GDBDriver.executeCommand(GDBDriver.java:2194)
        at com.jetbrains.cidr.execution.debugger.backend.gdb.GDBDriver.executeCommand(GDBDriver.java:2183)
        at com.jetbrains.cidr.execution.debugger.backend.gdb.GDBDriver.getVariables(GDBDriver.java:1272)
        at com.jetbrains.cidr.execution.debugger.CidrStackFrame$3.run(CidrStackFrame.java:146)
        at com.jetbrains.cidr.execution.debugger.CidrDebugProcess$MyCommandProcessor.consume(CidrDebugProcess.java:681)
        at com.jetbrains.cidr.execution.debugger.CidrDebugProcess$MyCommandProcessor.consume(CidrDebugProcess.java:674)
        at com.intellij.util.concurrency.QueueProcessor$2$1.run(QueueProcessor.java:110)
        at com.intellij.util.concurrency.QueueProcessor.runSafely(QueueProcessor.java:238)
        at com.intellij.util.concurrency.QueueProcessor$2.consume(QueueProcessor.java:107)
        at com.intellij.util.concurrency.QueueProcessor$2.consume(QueueProcessor.java:104)
        at com.intellij.util.concurrency.QueueProcessor$3$1.run(QueueProcessor.java:215)
        at com.intellij.util.concurrency.QueueProcessor.runSafely(QueueProcessor.java:238)
        at com.intellij.util.concurrency.QueueProcessor$3.run(QueueProcessor.java:212)
        at com.intellij.openapi.application.impl.ApplicationImpl$8.run(ApplicationImpl.java:400)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)
        at org.jetbrains.ide.PooledThreadExecutor$1$1.run(PooledThreadExecutor.java:56)

0

Please sign in to leave a comment.