Cannot get visual studio code to debug mono

[bkeys]

Operating system or device, Godot version, GPU Model and driver (if graphics related):
Fedora 26, master branch

Issue description:

I cannot find any documentation on how to integrate Godot's mono capabilities with visual studio code, is there a launch.json I can use for reference somewhere? @neikeq

[matrem]

Is there already a plugin to debug godot's mono integration?

[bkeys]

I want to say @Calinou mentioned that @neikeq might have done a debugging session with the default mono plugin for vscode

[akien-mga]

We have now entered release freeze for Godot 3.0 and want to focus only on release critical issues for that milestone. Therefore, we're moving this issue to the 3.1 milestone, though a fix may be made available for a 3.0.x maintenance release after it has been tested in the master branch during 3.1 development. If you consider that this issue is critical enough to warrant blocking the 3.0 release until fixed, please comment so that we can assess it more in-depth.

[neikeq]

I didn't make any editor extension yet because I'm still thinking how to make them communicate with Godot to be the most user friendly possible.

This is the launch.json I use with the default mono extension for VS Code:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Attach",
            "type": "mono",
            "request": "attach",
            "address": "localhost",
            "port": 23685
        }
    ]
}

That's the default port, but you can change it in project settings: mono/debugger_agent/port.

[olsonjeffery]

Hi, I'm using Godot 3.0 RC1 on macOS Sierra. I've got VS Code installed and set up with my launch.json config using what's shown in @neikeq 's comment above. I actually use VS Code for my main development experience and it works fine (w/ intellisense for Godot code or other dependencies I've added to the project via Paket/nuget).

I have the default debugger settings as shown in the project settings (port 23685). While the godot editor process is active, I notice that 23685 is open and I can connect from VS Code or telnet, but there's never any response to anything sent to that port.

When I build/run the project and then try to connect, its the same thing; I can connect in VS code, but no breakpoints are hit and it's unresponsive.

Also I've observed that, if I set the "wait for debugger" option in the project settings, any attempt to run/debug the project will stop immediately after debugging begins.

I understand that any dev work to address this will have to wait until after the 3.0 release, but I wanted to chime in with my experience.

[maikramer]

Is working perfectly to me, my steps, dont know what is mandatory:
Installed the mono debugger extension in vs code
Checked Install remote debug in godot
In project settings inside godot, i checked Wait for debugger
Set a bigger timeout, like 60000, to dont need to run
Pressed play in godot (the game start to wait for the debugger)
Back to vs code and pressed play debug, perfect
Using with ubuntu 18.04

[olsonjeffery]

Just attempted this again, on macOS Sierra, with the 3.0 stable release (64bit mono version). Have Mono 5.4.1 installed via brew.

Still the same behavior as I described above here

Can anyone confirm/deny remote debugging support w/ Godot+VS Code w/ Mono debugging extension on macOS?

[PJB3005]

I have definitely debugged C# code successfully with the Mono Debug extension for VSCode.

Wait for debugger is definitely broken however and there is an issue where the editor occupies the debug port. The latter is actually a problem because you end up debugging the editor which isn't running C# code to debug.

As for the editor port occupation issue: should we make a second config option for an editor port (so you can still debug the editor if editor scripts ever get implemented) or just make the editor not enable the mono debugger.

[PJB3005]

Actually nevermind on the wait for debugger thing. It works absolutely fine. Probably was fixed since I last tested it.

[neikeq]

I thought I already made the editor not enable the mono debugger:

godot/modules/mono/mono_gd/gd_mono.cpp

Lines 122 to 126 in 49dc473

	if (Engine::get_singleton()->is_editor_hint() ||
	ProjectSettings::get_singleton()->get_resource_path().empty() ||
	_is_project_manager_requested()) {
	return;
	}

I think at some point the editor should be debuggable, but right now there are a few issues with that.

[PJB3005]

Digging into this: the issue is with the project manager eating port 23685. The _is_project_manager_requested() doesn't work if the project manager was opened as a fallback.

[gattila]

I tested it with windows 10, mono 5.4.0, VS Code and mono debugger extension. I created a launch.json, started the game in godot and attached with the debugger. In VS Code I saw two threads: the thread#1 and the finalizer. I was able to pause the app from VS Code, in this case the Thread#1 was paused, and the game too, and I was able to continue it again, but unfortunately, the breakpoints wasn't hit.

[gattila]

Ps. I used the latest godot version (3.0.1).

[neikeq]

@gattila in which method did you put the breakpoint? Is that method async by any chance?

[gattila]

I simply clicked before the first line of the _Ready() function, and the big red button appeared, and I saw a new breakpoint in VS code in the breakpoints window. The code was executed, but the program was not stopped at the breakpoint. I debugged other .NET programs with VS Code before without any problem.

Maybe the mono 5.4.0 is too old ? I tired to remove the 5.4 mono and install the latest (5.10.0.140), but after the install (and the restart of the computer) the godot crashed if I tired to open a C# based godot application.

[gattila]

I tried with 5.4.17. The godot not crashing with this version, but it still don't stop on breakpoint.

[PJB3005]

The Godot builds provided on the website are built against 5.4 and don't work with any others due to other issues. The debugger does attach though, right? It just doesn't hit any breakpoints? Does the Godot process lock up when you hit pause on the debugger when it's attached?

…

On Feb 28, 2018 20:14, "gattila" ***@***.***> wrote: I tried with 5.4.17. The godot not crashing with this version, but it still don't stop on breakpoint. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#13837 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHu1ww_v7-eqBsmh7iLrLiVujmkyk85eks5tZaWhgaJpZM4Qzbca> .

[neikeq]

@gattilla Maybe that code is executed before the debugger is attached? What happens if you enable de option in Project Settings > Mono > Debugger Agent > Wait For Debugger? What if you put a breakpoint in a _Process method?

[gattila]

If I set the Wait for Debugger, the running app shows the godot splash screen and wait until I attach with the debugger. But it does not stop on my breakpoints, both on _Ready, _Input, _Process. These functions are executed: if I put a GD.print to these functions, I can see the result in the output window. I see the breakpoint lines in VS code, and the Thread#1 and Finalizer processes in the Call Stack window. I can play the pause button in VS code and in this case the godot application freezes, and the Thread#1 show Stopped status. If I press the Continue button in VS code the Thread#1 status changes to Running and the game also run as before the pause. All seems Ok, except the fact that the app doesn't stop on breakpoints.

[PJB3005]

Oh I should've asked this earlier. Are you on Windows? Pretty sure #14822 would break the debugger too since it wouldn't be able to associate line numbers with instructions.

[gattila]

Yes, it is windows 10.

[Duehok]

i confirmed the same behavior as gattila: on win 8.1 (it seems that I am the last person on earth who still use it), Godot 3.0.2 stable, Mono 5.4.1.7, VSCode + mono debugging extension: the debugger connects, the threads can be stopped, the breakpoints are not hit.

[exts]

same issue with jetbrains rider on windows. I get DWP Connection Failed.

[neikeq]

Marking this as Windows-only. Let me know if you can also reproduce this in other platforms. Debugging support will be added after 3.1, when we add extensions for some external editors and IDEs.

[PJB3005]

I'm looking into this.

So far I can confirm that embedded Mono debugging totally works on Windows in a tiny test project:

#include "stdafx.h"
#include <iostream>
#include <mono/jit/jit.h>
#include <mono/metadata/assembly.h>
#include <mono/metadata/mono-config.h>
#include <mono/metadata/debug-helpers.h>
#include <mono/metadata/mono-debug.h>

int main()
{
	mono_set_dirs("C:\\Program Files\\Mono\\lib",
		"C:\\Program Files\\Mono\\etc");

	mono_config_parse(NULL);

	mono_debug_init(MONO_DEBUG_FORMAT_MONO);

	const char* options[] = {
		"--soft-breakpoints",
		"--debugger-agent=transport=dt_socket,address=127.0.0.1:3005,embedding=1,server=y,suspend=y,timeout=30000"
	};

	mono_jit_parse_options(2, (char **)options);

	auto domain = mono_jit_init_version("thing.derp", "v4.0.30319");
	auto assembly = mono_domain_assembly_open(domain, "C:\\Users\\absolutelynotmyusername\\Documents\\Visual Studio 2017\\Projects\\mono embed debugging pls\\helloworld\\bin\\Debug\\helloworld.dll");
	auto image = mono_assembly_get_image(assembly);
	auto theclass = mono_class_from_name(image, "helloworld", "Class1");

	auto desc = mono_method_desc_new("Class1:Hello", false);
	auto method = mono_method_desc_search_in_class(desc, theclass);

	mono_runtime_invoke(method, nullptr, nullptr, nullptr);

	return 0;
}

and pasting said code into GDMono::initialize() does exactly the same thing, so debugging is something we're doing wrong with the Mono API I assume.

Not sure how helpful this info is but it's a start.

[neikeq]

I've been looking into this as well. So far, the debugger seems to be attached correctly. If there are no breakpoints, the applications run normally. If I set a breakpoint, the applications hangs indefinitely.
And no, it doesn't hang because it stopped at the breakpoint. I checked and the method is never called.

I will try removing unnecessary stuff from initialization until it's fixed, to find out what is causing it (if the problem is in the initialization that is).

[neikeq]

Aha! Found it. Preparing a PR.

[exts]

@neikeq so you half fixed it. I can get vs code on windows 10 to attach to the debugger now without issue.

• Project Settings -> Mono -> Debugger Agent -> Wait for Debugger
• Run the scene in godot
• Using the config above (and following these docs) -> Debug Tab -> Select Attach from Dropdown -> Hit Play

If I let godot project runs without debugging it'll timeout like normal and it'll run when the debugger connects without issue. Now the issue is the debugger isn't breaking any points for me. So close yet so far :(

• Windows 10
• Mono version 5.10.1
• Visual Studio Code (Latest)
• godot built off that version you merged

Weirdly enough jetbrains rider won't even attach to the debugger.

[neikeq]

That's weird. It did hit the breakpoint for me...

[exts]

@neikeq do you have a sample project that I can test to see if I can reproduce it working for you? Going to rebuild shortly to make sure (after i finish setting up ubuntu 18 & godot on my other desktop pc)

[PJB3005]

Definitely works on my end too. You changed the debug type of your project as instructed here right?

[exts]

@neikeq I just tested with mono 5.12.0 and it works perfectly. 5.10.1 doesn't work at all.

Maybe we should require 5.12.0 the required version? On their release notes they said this version passes a lot of their tests and improved a bunch of stuff so it only makes sense.

Edit: yup, jetbrains rider 2018.1 & visual studio code's debugging works with mono 5.12.0

[neikeq]

I have Mono version 5.10.0.160 installed.

[exts]

these mono versions are so weird lol. So 5.10.0 & 5.12.0 works? 5.10.1 doesn't for me.

[neikeq]

@exts Could you share a minimal example project where you cannot get it to work?

[exts]

DebuggaTest.zip

Just to clarify: 5.12.0 works fine, 5.10.1 didn't work, right now I'm building the editor using 5.10.0 to test if it works with that version. After I finish testing I'm going to redownload 5.10.1 and rebuild the editor again to confirm if it works or not with that version of mono.

[exts]

Alright I've rebuilt godot editor 3 times from master and I can confirm on windows 10 that:

• 5.10.0.179-x64 - works
• 5.10.1.49-x64 - works
• 5.12.0.226-x64 - works

Edit: Copy my message from discord: "I think I know why it didn't work on 5.10.1 the last time I tried it, if you have any errors in your code it'll attach but it won't hit any break points until you fix said errors. Retested with a very minimal project and it hits the breakpoint every time. "

[neikeq]

You mean compiler errors, or in vscode's editor?

[exts]

@neikeq correct. For instance, not instantiating a field that requires a instance would compile but throw an error to the Godot output yet the scene would still run. I'm on mobile so hope that helps.

Edit: Now that I'm at a PC, like a static Random field public static Random Rand; that'd compile, but error out resulting in the debugger not working (which makes sense) - I became tunnel visioned and just didn't realize until AFTER I tested with 5.12.0 and ruled that it was a mono thing when I tested a smaller project first instead of the project I had when checking the debugger.

[neikeq]

Oh, I think you are getting a NullReferenceException. As far as I remember, the mono debug extension for VS Code would not break on unhandled exceptions by default, but you could change that in the settings.

[exts]

@neikeq nice, just figured out how to do it.

    "mono-debug.exceptionOptions": {
        "System.Exception": "never",
        "System.SystemException": "never",
        "System.ArithmeticException": "never",
        "System.ArrayTypeMismatchException": "never",
        "System.DivideByZeroException": "never",
        "System.IndexOutOfRangeException": "never",
        "System.InvalidCastException": "never",
        "System.NullReferenceException": "always",
        "System.OutOfMemoryException": "never",
        "System.OverflowException": "never",
        "System.StackOverflowException": "never",
        "System.TypeInitializationException": "never"
    },

Adding this to your vs code user settings will catch said exceptions. I had to restart the editor for it to work, but yeah works as expected.