Unity Debugger Extension for Visual Studio Code 2.0.x Preview Release

I will try it out later today and report if there are any problems, just wanted to say thank you, epic!

Also, do you plan to add support for log points which vscode introduced in march update? I may try my hand with it if you don't plan to work on it. I want to help with vscode's handling of unity projects, I am currently working on PR to omnisharp which should fix handling of new/renamed files

 

Hi,
thank you for update.
When i try to put a breakpoint i get the error:

error while processing request 'setBreakpoints' (exception: An item with the same key has already been added. Key: [0, Mono.Debugging.Client.Breakpoint])

 

I tried it, looks like there is an exception CodeFighter mentioned every time I try to add more than one breakpoint. Only other thing I noticed is that hovering variables feels much more responsive than last time I remembered. Looking forward to next update

 

@miniwolf thank you for reply.
This happen after attaching debugger to Unity.

VS code -Version 1.22.1
Unity 2018.1.0b13
macOS 10.13.4

 

It looks like i found the reason.
I had list of old breakpoints from the previous version.
That is why error said about key already added.
I have deleted all breapoints and now it works fine.
Thank you for keeping of working on VS code plugin we really appreciate it

 

Thank you it works fine!

I found another issue. It looks like some of LINQ requests still not working in the debug session.

 

Yes it works in Visual Studio for mac and in Rider.

 

Great job!

I have an issue with breakpoints. When I disable breakpoint which was caught earlier, debugger will still catch it every time it executes this line of code. It's completely random and I cannot reproduce it on demand, but it's a little bit annoying.

 

just installed 2.4.0. Removing all breakpoints now cause error: "error while processing request 'setBreakpoints' (exception: Collection was modified; enumeration operation may not execute.)"

to clarify, problem happens every time I try to remove a breakpoint while debugger is attached

 

It works really well right now! It catches every breakpoint, and skip all removed BPs. Good work.

I found two more issues:
1. If you put breakpoints before attaching debugger, they will be "grayed" and debugger will skip them during execution. Once you put another breakpoint or remove one of the "grayed" breakpoints, they become active.
2. I found the way to freeze editor. Here is procedure to reproduce this issue:

• Open project
• Press play button
• After few seconds press it again (turn off the game)
• Go to vscode, then attach and detach debugger few times (press F5, then immediately Shift+F5, and repeat it 5-10 times)
• Go to unity and press play button again
• At this point editor is not responding to any command and I have to kill it

 

Thanks @miniwolf, nice work!

 

Hi there,

Thank you for your work on the extension. VS Code is definitely my favorite editor to use, however I still often have to switch to Visual Studio when I want to be efficient at debugging because of a few issues. My apologies if this is not the place to mention these, and I imagine they may be bugs with Omnisharp more than with anything's Unity but:

- I sometimes have the debugger hang the game when I try to stepin a function (I ended up sometimes just going into the function code and putting a breakpoint there instead, to avoid the freeze : ( )
- Can't watch member variable of collections elements (someArrayOfGameObject.name would not be possible to see even if I add a watch)
- Can't watch static variables

I've tried the latest version you posted here and it is still present, unfortunately : ( - Couldn't check the stepin freeze as it's not a 100% reproduction rate so can't be sure!).

Do you know if it's something on Unity or Unity extension side ? Or on Omnisharp side ? Is it something we could expect to see fixed ? (If it's Omnisharp I might even try to have a go at it myself!)

Thanks,

Clem

 

has anyone tried putting launch into user settings?
to keep folders clear of duplicate .vscode folders
i think it used to work... but now it seems not to? works as file but not in settings?
it might be a vscode insiders bug tho

thanks

4 minues later...

Code (CSharp):

1.     "launch": {
2.         "version": "0.2.0",
3.         "configurations": [
4.             {
5.                 "name": "Unity Editor",
6.                 "type": "unity",
7.                 "path": "${workspaceFolder}/Library/EditorInstance.json",
8.                 "request": "launch"
9.             },
10.             {
11.                 "name": "Windows Player",
12.                 "type": "unity",
13.                 "request": "launch"
14.             },
15.             {
16.                 "name": "OSX Player",
17.                 "type": "unity",
18.                 "request": "launch"
19.             },
20.             {
21.                 "name": "Linux Player",
22.                 "type": "unity",
23.                 "request": "launch"
24.             },
25.             {
26.                 "name": "iOS Player",
27.                 "type": "unity",
28.                 "request": "launch"
29.             },
30.             {
31.                 "name": "Android Player",
32.                 "type": "unity",
33.                 "request": "launch"
34.             }
35.         ],
36.         "compounds": []
37.     },
38.  

 

Thank you for looking into all that!

I unfortunately can't help much with the "Step Into" hang as it doesn't feel like it happens on the same type of function or in the same apparent conditions, but if I get more information, I'll be sure to let you know!

About the collection things. It would be in this case for instance:

Code (CSharp):

1. private SomeType[] m_SomeArray;
2.  
3. public SomeType GetHighestPriorityElement()
4. {
5.         SomeType highestPriorityElement = null;
6.         for(int i = 0; i < m_SomeArray.Length; i++)
7.         {
8.                 if(highestPriorityElement == null || m_SomeArray[i].Priority > highestPriorityElement)
9.                 {
10.                         highestPriorityElement = m_SomeArray[i];
11.                 }
12.         }
13.  
14.         return highestPriorityElement;
15. }

If you try and watch m_SomeArray.Priority when breaking at any line inside the loop, it won't work.
You can watch i, you can watch m_SomeArray (and find by yourself the element at index i), but you can't directly see the value of Priority inside the loop. While it's easy to see element in simple array like that "manually", it's much more annoying with List or more complex collections type.

 

I see this is only for visual studio code. ignore below


-What version of visual studio does this target. I'm on VS 2017 Community edition, but when I run the visx it states...-
-"This extension is not installable on any currently installed products"-

-I've attached the install log-

 

Hi there!

On macOS Sierra, Unity 5.6.3f1, VSCode 1.23.0, when I try to attach I get "Debug adaptor process has terminated unexpectedly" (this is v2.4.2 of the .vsix). Not sure if there's a log somewhere, so I can send you more info?

 

Nothing in any log. And after opening the developer console, the stack trace doesn't look too useful either, but see what you think:

notificationsAlerts.ts:39 Debug adapter process has terminated unexpectedly
e.onDidNotificationChange @ notificationsAlerts.ts:39
(anonymous) @ notificationsAlerts.ts:28
e.fire @ event.ts:140
e.notify @ notifications.ts:127
e.error @ notificationService.ts:61
t.onServerExit @ rawDebugSession.ts:540
(anonymous) @ rawDebugSession.ts:195
e.fire @ event.ts:140
(anonymous) @ debugAdapter.ts:273
emitTwo @ events.js:106
emit @ events.js:194
__dirname.ChildProcess._handle.onexit @ internal/child_process.js:215

 

@miniwolf Thank you very much!
I've actually tried again the update this morning (last time I was at home, now at the office ). And I'd like to say a big thank you because, it makes my life much easier : )

- Before that update, even adding an array element like that to the watch list wouldn't work, now it's ok.
- Inline Debug Values is the best thing since slice bread too. And it didn't work before I updated.
- Conditional Breakpoints working is great too!

Good job and thank you!

 

The 2.5.0 VSIX is missing attach.js again (see https://github.com/Unity-Technologies/vscode-unity-debug/issues/34).

 

It looks like VS for Mac made a fix for LINQ evaluating while debugging.
Hopefully it will be in VScode
https://developercommunity.visualst...45/immediate-window-cannot-evaluate-linq.html

 

@miniwolf I'm trying to use 2.5.0 with Unity 5.6.5, macOS 10.13.4 but like @joethephish I'm getting "Debug adapter process has terminated unexpectedly" when I try to attach. I already tried this process:

- uninstall extension
- remove .vscode/extensions/Unity.unity-debug*
- install 2.5.0

This has not helped. The log .vscode/extensions/Unity.unity-debug-2.5.0//bin/UnityDebug-log.txt doesn't seem to have anything of interest. I dunno if 2.5.0 was the version your mentioned that "has refactored much of the code and the way it interacts with vscode extension libraries"? Is there something else I can try or more info I can provide you with?

 

Hey,
the debugger crashes alot due to a stack overflow in UnityDebugSession.Evaluate in the call to Frame.GetExpressionValue.
I noticed it uses NRefactory which only supports C# 5.0. The code I'm debugging is using features from C# 7.2 (using the Incremental Compiler) and I guess this might be a problem. Debugging with VS is working perfectly.
Any information on this?

 

The stack overflow actually is a bug in Mono.Debugging:
NFactoryExpressionEvaluatorVisitor.VisitMemberReferenceExpression:

Code (CSharp):

1. public ValueReference VisitMemberReferenceExpression(MemberReferenceExpression memberReferenceExpression)
2.     {
3.         if (memberReferenceExpression.TypeArguments.Count > 0)
4.         {
5.             return ResolveTypeValueReference(ctx, memberReferenceExpression);
6.         }
7.         ValueReference target = memberReferenceExpression.AcceptVisitor(this);
8.         ValueReference member = target.GetChild(memberReferenceExpression.MemberName, ctx.Options);
9.         if (member == null)
10.         {
11.             if (!(target is TypeValueReference) && ctx.Adapter.IsNull(ctx, target.Value))
12.             {
13.                 throw new EvaluatorException("{0} is null", target.Name);
14.             }
15.             throw ParseError("Unknown member: {0}", memberReferenceExpression.MemberName);
16.         }
17.         return member;
18.     }
19.  

ValueReference target = memberReferenceExpression.AcceptVisitor(this);
Is a nearly direct call to itself. This is already replaced by
var target = memberReferenceExpression.Target.AcceptVisitor<ValueReference> (this);
in a current version of Mono.Debugger.dll.

Edit:
Using the current libraries from https://github.com/mono/debugger-libs fixes the crash.

 

I've had it twice now where Unity crashed while debugging (can't provide exact repro steps at this point) and the debugger tool removed the ability to add variables to the watch list. Last time I had to completely remove and reclone my project, which I rather not do again. Is there a config file with the debugger info that I can remove to reset the extension?

(just addtional info: I tried reinstalling the extension from the vsix on GitHub, and while it updated to the latest version, it didn't reset the extension)

 

@miniwolf_unity - thanks for the explanation.

For the UnityEditor crash, is not that unusual that it'll crash for me (or my colleagues, for that matter). Last time I opened a bug for me with consistent repro steps even, the answer I got was that it was something specific to Unity on Mac and not a priority to fix, which is why I didn't bother continuously sending crash logs.

For the extensions, the only common thread I have for now is a crash, variables in the inspector at the time, not being able to watch variables again (+ button / right click >> Add are disabled).
Luckily or unluckily it hasn't happened that many times that I can narrow down repro steps, which is why I didn't see the point in filing an issue on github.
I have a "feeling" that on both occasions the crash happened while I was expanding a variable in the list and the debugger was working on showing the extended data. Since there's a known issue with LINQ and I use it fairly often, that could be part of the problem (last time I was for sure in a scope with a LINQ call that wasn't working 100% of the time, but I don't THINK I had a breakpoint in that line).
If it's still helpful to log an issue with this little information, I'll be happy to do so.

 

@miniwolf_unity - thanks, I appreciate it!

I don't have a link to that issue anymore, but it's still happening (up to 2017.3.1f1, at least).
I can open it again if you'd like (it has to with Unity not handling an improper getter, where by accident you may have indicate given the same name to the getter and a variable you're trying to return like bool

_myBool { get { return _myBool; }}

.

On a more current note, Unity just crashed on me again, this time with a breakpoint on a delegate call. I wrote a report this time. Tried to send it, and the Unity Bug Reporter showed as stuck in the "Packing the report" stage, so maybe it was sent, but I would not expect it to have made it through.

As for the extension, I've logged https://github.com/Unity-Technologies/vscode-unity-debug/issues/91, with what I do know, even if it's not enough for reproduction.