I am trying out GoLand and hear that the debugger is supposedly awesome, but I can’t find any documentation explaining how to set it up (GoLand is in preview stage, so that’s not really surprising). My use case: I am writing a REST API to which I send requests using curl. Could someone please tell me, step by step, how to get started with the debugger ?
[edit 1] (moved from comment) When I click Run/Debug (or Run/Run), a window is displayed, asking me to edit configurations. I am given a choice of several kinds of configurations, I try to choose "Go application" but the Debug button never is grayed and I can't get it to become clickable. I am very new to GoLand, I may be missing something obvious, but I can’t find whatever settings are missing.
[edit 2] It turns out that my workspace did not conform to the Go specifications : my code was not in a directory named src. Now that it is the case, I can click Run/Debug and GoLand seems to be doing the right thing, except it doesn’t stop at breakpoints or otherwise behave like a debugger, my code just runs.
[edit 3] Tried again, and it works. Sort of. I have no idea why it works now, even though it didn’t previously and I didn’t change anything. Now breakpoints work at some lines, and not at others. Or the debugger stops at the breakpoint, but I wait forever for the list of variables to be loaded. Well, it is a preview, after all...
[edit 4] I was notified just today that a new version of GoLand was available. I upgraded, and debugging is working well for me now.
GoLand will not enable the debug action (although run is available) if your code does not reside inside src. There is no warning about this, so it might be really a pain to solve this.
Additionally, depending on your project’s structure it might be possible, that debugging is still not working. In that case, it might help to remove all run configurations and create a new one. There’s is a bug report about this behavior.
PS: Although the OP mentions the first part in an edit of the question, but it think it’s worth mentioning in an answer.
Things changed in goland since #Jamillo Santos added his reply.
To start with, there's no more "Go Application".
The easiest way is to locate the file containing the main() function.
There should be a small triangle pointing to it, like in the attached screenshot:
When you click on the small green triangle, you get a menu with Run/Debug options.
Each will create a go build configuration.
You can edit that go build configuration and add the program arguments for your application.
For example, if your program have a command line argument of --arg=value you can add it like this:
I was facing this same issue and I solved by using the "Go Application" configuration (at the Run/Debug Configurations window), instead of the "Go Single File" configuration.
So, go to the upper right corner of the Gogland and "Edit configurations".
Then, add a new configuration using the "Go Application" profile.
After saving, you should be able to debug your code. o/
An easy way to enable this configuration is to use the #user1793301 method and right click on the file you want to run and select "Debug 'go run .go'".
POSSIBLE EXPLANATION
NOTICE: I did not look any further details about it.
Fact: "Go Application" configuration does build the binary executable before running it.
Fact: I could see looking at the console output (inside of the Goglang) is that the IDE uses the DLV as debugging tool.
Fact: I found a dlv debug at the DLV documentation and it seems to compile and debug the code.
Hypothesis: The guys from Jetbrains did not implement it. Or at least not YET.
On version 2019.1.1 there's no more Go Application. Use Go Build instead. Here I am debugging a single script file, but if you have a server app or smth, just point to the main app file:
Notice that in the Files field you have to specify the actual file path. You can put more files (if you want to have more starting points) by separating them with a pipe |. For each file you want to be able to debug, you need to specify the full path.
Again, if you are debugging a server app or something else, that has a single starting point, you only need the startup file specified in the config. :)
I had this exact problem.
Deleted and recreated the Debug run configuration. Debugging then worked perfectly.
I followed the following procedure to start my golang server in debug mode. (You might want to use some other method than creating a makefile for starting your server maybe)
Create a makefile
Define your server/worker startup command in the file
Run it by creating a new configuration for Makefile
Go to Run -> Attach to process -> choose your running server
This will attach the debugger to your process.
Note:
You might need to restart your server for this to work.
The IDE will ask you to install gops, do install it. Without installing gops you won't see any running process.
I right click on project (main.go inside) and choose "Debug ..." and it work
Related
I left VB6 and programming all together years ago, so pardon since I'm still dusting off what I remember.
I have an old program made for a friend in VB6 that he still runs in Windows Vista. He tried to update a label in the program and in trying to do the update, he has overwritten the project file where I used to see all forms and modules together.
Is there a way I can recover or recreate the project file as it was? All project files and modules are there, but when I open the VB6 project it shows only one form, that I can't compile or execute because it shows a "source not found"
I tried to go back to an old version of the project file with file recovery software but I couldn't find it.
Other way?
Practical steps to recover:
First and foremost: Back up what you have. Do this now.
Second, and only after the first, check (again) to see if you have a previous backup. Yes, this may seem pedantic, but, really, it's worth looking. Was that the only copy? Once you do all of this, consider creating a git repo for your code.
Third, in your empty project, simply right-click in the project explorer (Ctrl + R), and click "Add >" and then "Add Files...". Then, in the file input box, scroll down to the first file, hold down shift, and keep pressing the down arrow and all the files you want. Click "Open". Repeat if need be.
Finally, you need to re-add any dependencies. One way is simply to try to run the program with full compile (Ctrl + F5 or File | Run With Full Compile in the menus). If everything starts up, consider yourself fortunate. If not, you'll have to see each one that fails and add them back. This could be tedius, but just go through them one by one. In the Project menu, both "Components" and "References" can be gone through. Do this until the program successfully starts with full compile.
At this point, consider a making a backup. ;)
I'm fairly new to OSX development. I'm currently writing an app which has its own (cross-platform) custom XML-based file type.
I want to write a quick look plugin so that things look good in the finder, and have found the tutorial on how this is supposed to work, but apparently I must be doing something wrong since I see in /var/log/system.log that I get a segfault when my Quick Look plugin is ran. I'd like to see where it's crashing, but I can't for the life of me figure out how to do that.
Where does OSX store core dumps (if it even does that)? Do I need to set some system option or something to enable that?
How do I get Xcode to look at these core dumps?
I'm lost.
EDIT SIP prevents you from debugging protected processes. Because of that, it is currently (at least since SIP was introduced, through Mojave) impossible to debug QuickLook plugins without turning off SIP, at least partially.
As you've probably discovered, since your QuickLook plugin is a plug-in instead of a standalone executable, you need to debug the process that hosts the plugin. To do that, you can hook yourself to the qlmanage executable.
The first step is to make your .qlgenerator plugin available to the Quick Look server. To do that, you need to copy it to ~/Library/QuickLook and run qlmanage -r. The first can be implemented as a post-build action, the second has to be specified in the debug options.
For the post-build action, you should follow these steps:
hit Alt+Cmd+R to open the run configuration window;
unfold the "Build" tab on the left and go to post-actions;
click the plus at the bottom of the window and select "New Run Script Action", and use the following code.
absolutely ensure the "Provide build settings from" is set to your QuickLook extension target.
rm -Rf "~/Library/QuickLook/$FULL_PRODUCT_NAME"
cp -R "$BUILT_PRODUCTS_DIR/$FULL_PRODUCT_NAME" ~/Library/QuickLook
qlmanage -r
Then, you need to configure Xcode to launch qlmanage:
in the same window, go to the "Run" tab, and select "Info";
in the executable drop-down menu, pick "Other...";
hit Shift+Cmd+G to enter a path, put in "/usr/bin/qlmanage", and select that file;
check "Debug executable" if it isn't already;
move to the "Arguments" tab, add a "-p" argument, and then add arguments as you see fit for the files that you need to preview.
Now, when you use the Run action, you'll be able to debug your plugin through qlmanage.
I haven't tried this personally, but this page:
Debugging Quicklook Plugin in Xcode 4.6
has a description of how to debug your plugin in Xcode 4 - 6. That will probably be much more useful than trying to grub through the core file after the fact.
.NET 4, console application. The project is set to 'Debug' mode. The breakpoint being set is in the primary/startup project. I have right-clicked -> Clean, and right-clicked -> rebuild, both on the Solution and project levels.
Following the instructions in this SO question, I have confirmed that my "Build and Run" options are set to 'prompt' for both 'When projects are out of date' and 'when build or deployment errors occur', and I am NOT getting a prompt when I F5 to build/run.
Also, the 'save all changes' under 'before building' is also selected (plus I manually saved them myself).
I monitored the output window of the application, see this line:
'MyApplication.exe': (Managed (v4.0.30319)): Loaded 'C:\exepath' Symbols Loaded.
I restarted the VS2010 instance. I restarted all open VS2010 instances (of other projects). I've even gone through a reboot.
However, the breakpoint I am setting in the startup project is a hollow-red circle, with the notice that 'This breakpoint will not currently be hit, The source code is different from the original', and, in fact, is never hit.
So, this is really 2 questions:
1) How do I fix this problem so I can properly breakpoint
2) When I see this, does that mean my code is executing from an older build?
I've had this problem once myself but that was on a vsto addin. In that case there were left over intermediate files under the users/appdata directories that were actually loaded instead of my app.
There is this blog article that has a whole load of possible reasons for this error and then a whole bunch more in the comments from other users
This can also happen if you have a solution with multiple projects, and have the wrong project selected as your startup project in VS2010 and VS2012.
Now, obviously, I wouldn't expect debugging to work if I have the wrong startup project selected -- the debugger is attaching itself to the wrong process!
But this error message (in my case) was terribly misleading. It made me think something else was wrong. I tried a bunch of solutions in this thread (nuking various /bin and output directories) when really it was something very simple (wrong startup process).
If you are using vb, check that you are building the project for the active solution configuration (Build, Configuration Manager..., Column under Build is checked. Also check the project properties, Compile tab, Advanced Compile Options, and Generate debug info is set to Full. Sorry I can't tell you where this may be in C#.
The only other time I've seen this is when two projects in the solution are referencing the same dll but they are referencing from different sources. One from a project reference and another from a file reference for example. If the "copy local" option is true, there would be the potential of overwriting the dll with an older version of the same dll.
My solution might help people who have signed the assembly.
After lot of head scratching for the past two days, I was able to resolve the same issue by doing the following simple steps:
Go to your Visual Studio project properties.
Go to the "Signing" tab.
Uncheck "Delay sign only" option if it is checked.
Now run your project and it should work.For me it did work.
In my case was this same problem (“The breakpoint will not currently be hit. The source code is different from the original version.”) caused by fact, that I tried add breakpoint to declaration:
DateTime dt;
bool b = DateTime.TryParse(null, out dt);
(first line of code)
So I assume that message is "universal" and may have many different causes.
This can happen if your system clock was changed since the last compile. Your PDB file will be different date than the one your are trying to debug. Delete the PDB files in the project and recompile.
I experienced the problem when Project > Properties > Web did not have "Enable Edit and Continue" selected. After enabling this feature the issue was corrected.
It is important to note that under Tools > Options > Debugging > Edit and Continue "Enable Edit and Continue" was selected, but it was not enabled for this project.
Just go to Tools / Import and Export Settings
Choose reset all settings then click Next
No, just resetl settings, ovewriting my current settings then click next
Choose your current language, por example C#. then click Finish
If you have multiple solutions open, try simply closing all Visual Studio instances and restarting only the instance you need.
In my experience this has happened when two branches of nearly identical code are open in different instances.
doing a "clean solution" from VS Build Menu might help you.
I had to go over all those steps to fix the issue on my computer.
Make sure that debug = "true" on your web.config
Clean and rebuild all projects
Delete every file inside the bin folder of all projects
Close and open Visual Studio, rebuild, and run the project again.
Go to your solution folder -> obj -> Debug - > delete the .dll file and build the solution again.
My Visual Studio 2010 debugger sometimes has a very strange behaviour...
Sometimes it doesn't stop at breakpoints, but when it stops, and I want to step into a method, the debugger just steps over it. Also the breakpoints in those over-stepped methods are ignored.
When this strange behaviour occurs, it also does not break on exceptions but simply ignores them.
I've tried to rebuild my project, reset the Visual Studio settings and disabled debugger settings like "Break only in my code", but nothing has worked.
How do I solve this problem?
Here are a couple of reasons and workarounds for why Visual Studio will avoid stepping into a particular method.
Just My Code is enabled. In certain circumstances the "Just My Code" setting will prevent you from stepping into a method / property. To avoid this you can disable "Just My Code" in the debugger options page (Tools -> Options -> Debugger -> Uncheck "Just My Code")
Symbols are not loaded for the target method. If the target method is a part of another DLL it's possible that symbols are not loaded for that DLL and hence Visual Studio will not be able to step into it by default. To force the symbols to load, open up the Modules view (Debugger -> Windows -> Modules), navigate to the DLL containing the method, right click and load symbols.
The method is explicitly marked with a debugger attribute such as DebuggerNonUserCode which causes the debugger to step over the method.
The method is actually a property or operator and you have "Step Over Properties and Operators" setting enabled (this is the default). This can be disabled via the debugger options dialog.
In my case it was "Step Over Properties and Operators" in Tools -> Options -> Debugger. Just had to uncheck that and after that everything was fine, I could step into.
Another source of confusion is iterator methods that use the yield return operator because they are rewritten by the C# compiler in such a way that stepping into them (F11) is kind of a "no-op".
You must wait for the iteration to occur to break into the method's code.
I've found the solution of the problem and it is really simple:
In my solution's build configuration, the "Build" check-box of the project where the methods are, that get over-stepped, was not checked. I checked it, and now everything works.
The most important thing to check is whether when trying to put a new breakpoint inside the method it refuses to step into, if the breakpoint is filled red liked the others, or half filled or has a special "look". If it does, hover over the breakpoint you created to find out why it isn't working.
If the breakpoint looks normal but still you can't seem to step into the method, try clearing the shadow copy cache: http://weblogs.asp.net/mreynolds/archive/2003/08/11/23576.aspx
Another thing to try is to make sure that you are indeed using the DLL you've just rebuilt by adding a MessageBox.Show (or something similar) to the method you can't seem to stop at, and make sure you get the box.
I struggled with this for a while. None of the answers given worked for me. I finally got it to work by doing the following:
Make sure the project is in debug mode (all projects)
From Windows go to a Command prompt and be sure to run as administrator
Navigate to c:\windows\syswow64\ (or folder where gacUtil.exe is located)
Run the following command (substitute path below to where your debug output version of the DLL is located.
gacutil /i "C:\Users\John\Documents\Visual Studio 2008\Projects\Project1\Project1\bin\Debug\MyAppDLL.dll"
You should get "Assembly successfully added to the cache"
Now run your project and you should be able to step into the DLL code.
WAG here, but I'd say you've referenced another project in your solution by BROWSING to a dll (project/bin/debug/mydll.dll) rather than by adding a "Project Reference." If you have multiple projects in your solution, remove ALL references to each project. Then, in the Add Reference dialog, hit the "add project reference" tab and select the project you wish to reference.
Project references are always updated on a new build. But if you, say, browse to bin/release and add a reference to a dll in that directory, when you switch to debug mode and add code and try to debug it, the old release version of the dll is loaded into the appdomain and VS won't be able to hit any breakpoints (you'll notice the breakpoints are empty circles and the tooltip will say something about the code not being loaded).
I have just found another reason for the problem, and a fix. I am creating a Windows Forms application using C++ in Visual Studio 2010. I am using the FreeType library and some code which depends on it and for various reasons this code has to be compiled with 'No Common Language Runtime Support' selected (Properties -> Configuration Properties -> General). I was not able to get breakpoints to be hit in this non-CLR code.
The fix is that the main app must be compiled with 'Common Language Runtime Support (/clr)', NOT 'Pure MSIL Common Language Runtime Support) (/clr:pure)'. That immediately solved the problem. I can now debug into, and hit breakpoints in, the non-CLR code, including the FreeType C code.
I have experienced the same recently. Not sure what I did exactly though. Try to physically clean up your solution, i.e. delete all bin directories from all projects of the solution. That usually helps to solve a lot of problems.
Try disabling "Require source file to be exactly matched" option in tools->options->debugging->general.
My solution was to create a new project and load all my .vb files into the new project. Solved all of my issues.
My problem was simple. I have multiple projects in the solution and I just need to set the project I am working with as Set As Startup Project.
i have a XCode project (my main xcode project which has its executable). It has dependencies on a few other projects (under the Project tab in Detail View, there are a few other xcode project that it depends on).
My question is how can I setup breakpoint in the code of the dependent project?
I tried this, but this does not work
1. open my main xcode project
2. double click one of the dependent xcode project
3. in the source directory, find the file I want to break and add a breakpoint (by click at the side of the border of the editor, a blue 'bookmark thing' shows up)
4. Go back to 'Build and Go', my application does run but it never breaks at the break point I set in #3.
Can someone please help me? I have spent days on this, I can't figure it why.
Thank you.
1) Add the breakpoint in your project
2) Go into breakpoints view in xcode (top left besides project navigator) The view's icon is like a breakpoint icon
3) Right click on the required breakpoint and select "Move to" -> "User"
If the breakpoint is under "User" project, then it is accessible by all projects.
Whenever I've had trouble setting breakpoints with the Xcode GUI, I've managed to do it with the debugger command line (that is to say, the "lldb" prompt in the output window). For example, to set a breakpoint in source file "client.m" at line 42, type:
(lldb) b client.m:42
Besides being a fix for this particular problem, debugging on the command-line offers far more flexibility and automatability than any GUI could. A good place to start would be the LLDB tutorial. (Full disclosure: I'm a longtime fan of unix and gdb, so there's some bias here).
Of course, as others have mentioned, make sure the library/dependant project is compiled with debug symbols. Hope this helps; good luck.
I'll echo Jon-Eric here and also add that if you habitually run your project with Cmd+Enter, you should consider switching to Cmd+Y to enable gdb each time.
a few things here...(some obvious some not)
1) be sure that the dependant project is compiled with debug symbols (i'm assuming its a library)
2) be sure that your active executable is linking against the debug version of your dependent library
3) set a breakpoint in your main project just before calling into the entry point of your lib, and set a bp on the entry-point of the lib... (in addition to the real breakpoint you are looking to hit...)
I have found that the best way to debug a library is to open the lib project and set the active executable to be the main project, and then just hit "build and debug" directly from the library project.
I hope this helps, good luck, and have fun!
I've had similar problems with Xcode. The solution for me is to make sure that there is also a breakpoint in the main project that gets hit (as Kent mentions in his third point). I don't understand why this works though.
You should also only set breakpoints in a project when you've got it open. If you don't, they can start misbehaving: still stopping the flow of execution after you've disabled or deleted them, or not working when you think they're enabled.
Make sure you select 'Build and Debug' (for step #4). 'Go' sometimes means 'Run' (breakpoints disabled) and sometimes means 'Debug' (breakpoints enabled).
Also, make sure that you leave the dependent project open while you debug the main project.
In addition to kent reply about debug symbols, check COPY_PHASE_STRIP value in the build settings of the main project, and be sure it is set to NO in debug.