The Debug button is disable, Shift+Alt+F9 will show this:
How to properly configure the debug page?
Update. The Go plugin supports Delve on Linux and Mac since September 2015 and on Windows since January 2016.
Original answer:
Currently we are dropping support for the debugger with gdb as it's very hard to use and unstable. Please see the go docs for gdb debugging
However, there are efforts in getting the open-source Delve debugger support for IDEs from which IDEA will benefit as well.
Please bug the Go team to support Delve or another debugger in order to have a stable solution and then integration with IDEA could be done.
thanks ,solved it.
Intellij Config is not right
The debug feature was introduced by issue 25, and commit 3a21e14
The correct way is to implement the debugger interfaces in inteliij and to hook them to a running gdb process.
(Here is an example of manually calling gdb to debug a Go program; using the options -c -gcflags '-N -l': not sure if the -l would matter as it is missing from the OP's screenshot "Go builder arguments")
It is possible the debug button is disabled if no gcc is configure for the Go debug process to use.
Note also that since PR 644:
"Debug" is disabled, if "Build Before run" is not enabled.
This should fix the problem, when gdb wants to run a not existing executable, because the outputDir is not set.
Related
I recently ran into an issue that I want to share Q&A style here. Hopefully it will help others, at minimum it is documented so I can find it later :)
When trying to run Ncurses in CodeBlocks it blows up when it hit initscr();. With VSCode this was not a problem, so I know there was something I am missing. With the help of StackOverflow it appears the best way to approach this with gdb (and CodeBlocks) is to attach to the process itself after it is running, rather than starting it in CodeBlocks. (Debugging ncurses application with gdb)
However, when I try to attach to the PID it just says that it was unable to attach to the process. Why is this?
I found that if I tried to run it through gdb on the commandline I also got this same issue. It comes from Kernal Hardening to prevent hacking. With this answer: https://stackoverflow.com/a/32274645/1770034
I discovered I needed to switch over to the root user. Then run echo 0 > /proc/sys/kernel/yama/ptrace_scope Now Code blocks will happily attach to the process and you can use your break points.
I'm having trouble getting IntelliJ to recognize which source files correspond to the thing I'm trying to attach a debugger to. The project in question is a Gradle project running locally, using Java 1.7. (EDIT: I'm actually also running that project from within IntelliJ, and that's also what's building it. It's a Gretty task defined in the project's build.gradle file. I'm passing
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5006
to the JVM to open the debugging port.)
I can tell that the debugger is attaching to the process correctly since I get the "Connected to the target VM" message. But breakpoints do not get the checkmark, and they aren't hit during execution. (EDIT: This is leading me to believe that the sources aren't being attached -- The debugger is attaching to a process successfully, and I have reason to believe that process is the one I want since I'm using JVM arguments on it to open the debugging port, but it appears to me that the IDE doesn't recognize what source files correspond to the running code.)
The other person who works on this code does not seem to have this issue. He's on an older version of IntelliJ. His "use module classpath" dropdown has a <whole project> option and mine does not (though it does have <no module> -- is that the same?). Unsure which version of IJ he's on specifically; I'm on Ultimate 2018.3.
I'm sure that I need to include more information than this, but due to my unfamiliarity with Gradle as a build/run tool and with how remote debugging works in general, I don't know what information I'm missing -- of course I will provide it as soon as someone asks me for it.
BIG EDIT (and probably the real answer here): I have a feeling I'm attaching to Gradle itself rather than the task. If I choose Run -> Attach to Process, the dialog shows me "45039 org.gradle.launcher.daemon.bootstrap.GradleDaemon (5006)".
As an daily IntelliJ user you usually concentrate on the projects you are working on and IntelliJ is just a tool. You are not willing to dig into tool's problem itself. But this is what is forced on you by default after IntelliJ installation on MacOS and opening relatively big project(most of the projects nowadays are huge and have thousands of files and use numbers of IntelliJ 3rd party plugins).
Here is a minimal list of actions. IntelliJ must have set MORE RAM to be used by default.
Read: https://intellij-support.jetbrains.com/hc/en-us/articles/207241085-Locating-IDE-log-files .
From IntelliJ open Help / Show log in Finder and open idea.log file with Console.app; In Console.app press "Reload" and "Now" buttons to track "live" what IntelliJ is doing.
If in logs of IntelliJ you find that some of the plugins exit with fatal error, you just uninstall those plugins. For me the one that failed to the moment of this answer was "BashSupport" as example.
Start Terminal.app ; Run command: open -a TextEdit /Applications/IntelliJ\ IDEA.app/Contents/bin/idea.vmoptions ; Change options in idea.vmoptions file to:
-Xms1024m
-Xmx2048m ; Read https://www.jetbrains.com/help/idea/tuning-the-ide.html to see how you can tune IntelliJ for your project. This step is handy when your IntelliJ app doesn't start at all and you want to change properties in a global way.
From IntelliJ open Help / Edit Custom Properties.... Here you can set same properties that will override global and will work only for current OS user.
Also there is also a possibility of underlying OS to do it voodoo magic so the IntelliJ won't work as it should like here - https://intellij-support.jetbrains.com/hc/en-us/community/posts/360000398280-IDEA-Ultimate-2018-2-Unable-to-save-settings-Unable-to-create-file-Windows-10
Make sure your project build output for *.class files is set. Read: https://intellij-support.jetbrains.com/hc/en-us/community/posts/360000000584-Build-does-nothing . In my case when IntelliJ started project build it terminated without warnings shortly after.
Finally in my case none of 6 steps above solved the issue so I found this read: https://intellij-support.jetbrains.com/hc/en-us/community/posts/115000532044-IntelliJ-cannot-build-projects . Basically try reinstall IntelliJ from original distribution again.
I know that you must read https://www.jetbrains.com/help/idea every time you install a new version of IntelliJ, but why not to add some consistency into configuration process of the main java process that runs IntelliJ itself? You can ask how much ram to use during installation of IntelliJ and explain why it is so. Then Help digging won't be necessary in the first place for devs who fed up with changing those default settings that will be always more than 700MB. I think for most devs out there it is at least 10x of that. I bet what makes most devs mad about this is not the fact that you need to do some options changing, but where those options are depending on OS plus the fact that you simply forget why IntelliJ app just exits while you are doing a debugging of your own app. I bet this problem makes us mad since first java based IDEs appeared. User-friendly is the key here and explicit reminders within the app itself would help.
I want to integrate features into MonetDB, more specifically into the dictionary part of it. I found some information here, but this is not really elaborate.
The concrete feature I want to integrate is secondary in my question here. My biggest hurdle at the moment is: how do I start to develop MonetDB?
I was able to download the source and build it as described here. But where to go from there?
My preferred way would be: get MonetDB in some form of an IDE, set various breakpoints, send a SQL query and explore the code from there.
Is this possible? What development environment do you use? Is gdb debugging the only possibility? How do you debug?
Meanwhile, I figured it out myself. Maybe, somebody else will face this problem, wherefore I answer my own question. I finally ended up with Eclipse and describe a possible way to start MonetDB development/debugging:
Clone MonetDB repository from the official repository, e.g., from Github
Download the C++ version of a current Eclipse release
In Eclipse click on File > New > C/C++ > Makefile Project with Existing Code > Next. Insert the cloned repository dictionary as Existing Code Location and select the GNU Autotools Toolchain
Now you should be able to build MonetDB inside of Eclipse
After a successful build, you can choose Binaries from the Project Explorer. There you can right click the different binaries and use to run as or debug as
This finishes the setup of MonetDB inside Eclipse. Now, it depends on what you want to debug. If you want to change something at the server, you might want to debug monetdbd. My tips to do this are:
Start debugging of monetdbd per right click as explained before
Close the debug session and adjust the debug configuration
On the Arguments tab, insert the arguments: start -n <path to your dbfarm>. This will keep the database daemon from going into the background
On the Debugger tab, select Automatically debug forked process and optionally Non-stop mode
A new debug session will now automatically stop at the main of monetdbd and will also show the threads of the forked mserver5 process
I'm developping golang porjects using IntelliJ IDEA 15.
In advance I installed GDB to debug on mac.
Then I want to debug golang projects using GDB on IntelliJ IDEA.
However, I could't find how I can do that.
If someone know, please give me a advise.
Thank you in advance.
As of today, no, you cannot. However the plugin comes with Delve integrated which makes the debugging experience better for Go apps (if you are on the supported platforms by delve). See the debugger link: https://github.com/derekparker/delve
Once GDB will properly support Go apps, things might change of course.