Debugger Fails to start when attempting to debug test

[ghost]

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.1)

Product Information:
 Version:            1.0.1
 Commit SHA-1 hash:  005db40cd1

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.12
 OS Platform: Darwin
 RID:         osx.10.12-x64
 Base Path:   /usr/local/share/dotnet/sdk/1.0.1

VS Code version:
1.11.2 & 1.12.0
C# Extension version:
1.9.0

The following lines are in my .csproj files as well:

<TargetFramework>netcoreapp1.1</TargetFramework>
<DebugType>portable</DebugType>
<RuntimeFrameworkVersion>1.1.1</RuntimeFrameworkVersion>

Steps to reproduce

• Create an test class using xunit with a test

public class UnitTest {
  [Fact]
  public void TestFoo()
  {
    Assert.True(false, $"{nameof(TestFoo)} was run.");
  }
}

• Place a breakpoint
• Click the "Debug Test" CodeLens link

Expected behavior

The debugger launches, PDBs are loaded, and VSCode hits a breakpoint.

Actual behavior

The first time, the debugger loads, but no PDBs are loaded so VSCode never hits a breakpoint.

The second time, the debugger fails to load and VSCode presents the message: "Failed to start debugger: null"

[gregg-miskelly]

@fedoranimus can you look in the debug console during the first launch, and see if you get a message like:

WARNING: Unable to connect to debuggerEventsPipeName '{0}'. {1}

If so, what is your complete message?

[powellcj12]

I finally tracked down what caused me to encounter this (as mentioned in the previous issue). Possibly somewhat of a different (but maybe related?) issue.

In my test directory, I remove the obj and bin directories from whatever the previous build output was. Then I change to have the TargetFramework in my csproj file:

  <PropertyGroup>
    <TargetFramework>netstandard1.5</TargetFramework>
  </PropertyGroup>

Trying to to dotnet test (after the requisite dotnet restore; dotnet build) will fail, and if I try to use the 'debug test' option in the GUI I get the error message:

Failed to start debugger: null

I consider this "user error" though (after doing a bit of research) so I switch back the TargetFramework to netcoreapp1.1. Now I can get dotnet test to run/succeed but still get the same error trying to use the GUI. Things then go back to normal if I restart VS Code or remove the bin/obj directories and rebuild.

So seems like there's some issue about which build output the extension is using when launching the debugger from the GUI? Again, that's probably different than the core issue going on here - let me know if I should open a separate issue for that.

[ghost]

@gregg-miskelly I do not see that line in the Debug Console, I just see a long list of Loaded '/usr/local/share/dotnet/shared/Microsoft.NETCore.App/1.1.1/System.Private.CoreLib.ni.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.

However, I do get a VSCode error sometimes as well: Debug adapter process has terminated unexpectedly

[gregg-miskelly]

@fedoranimus RE: 'Debug adapter process has terminated' - by chance do you have repo steps? If you can enable logging that might allow us to track down what is going on. Unfortunately you will need the 'full' method for unit test debugging scenarios.

[gregg-miskelly]

I should also say - the 'Skipped loading symbols' messages are normal.

[ghost]

@gregg-miskelly Yup, I expect the 'skipped loading symbols' messages.

I'll enable logging and see what comes up - thanks.

[StephenRedd]

I'm seeing the same problem with xunit tests. Clicking run test works, debug test doesn't... it either dies quietly, or throws up "Failed to start debugger: null". The same project works perfectly in VS 2017 though.

Turning on engineLogging as outlined here does not create a log file when using the codelense links, nor is any error shown in any of the output windows.

In this case, this is a .net core 1.1 class library project with an xunit test project. The csproj settings are identical to the ones in the initial description above.

[ghost]

I can echo what @StephenRedd says. I do not see a log file created and the Debug Console doesn't display any warnings or errors.

My reproduction steps are that I open VSCode, navigate to a test class and press the "Debug Test" codelens link. The first time the debugger will start but not hit anything. All subsequent times I'll get the Failed to start debugger: null.

Is there anything else I can do to provide additional information?

[DustinCampbell]

Could you provide your OmniSharp Log?

[ghost]

Where is that located?

[DustinCampbell]

Sorry, forgot to mention it.

In VS Code, select View->Output. Then, choose "OmniSharp Log" from the combobox in the top-right corner of the Output pane.

[ghost]

Here is my log

I noticed one line in it that may be interesting:
[warn]: OmniSharp.MSBuild.MSBuildProjectSystem Failed to process project file '/Users/timdturner/Github/covalence-server/src/Covalence.API/Covalence.API.csproj'. /Users/timdturner/Github/covalence-server/src/Covalence.API/Covalence.API.csproj(1,1) System.InvalidOperationException: The operation cannot be completed because a build is already in progress.

[DustinCampbell]

Any chance you could share your project?

[ghost]

I cannot, sadly.

[StephenRedd]

You can fork the NullMailer repo to reproduce

• Open vs code for the the repo root folder.
• Pick a test in the "NullDesk.Extensions.Mailer.Core.Tests" project
• Debug test

Attached is the omnisharp log when I do the exact steps listed. In this case, the debugger just didn't start, but it did not give the pop-up error... when this happens there is no indication if anything is happening outside of the output windows.

nullmailer-omnisharp-debug-log.txt

[DustinCampbell]

@StephenRedd:

[StephenRedd]

Can I borrow your computer for a few weeks while we work on our other projects having this problem?

I have two systems where this doesn't work, but I'll verify by going to one of our servers where none of this is installed --then installing fresh VS Code, the dotnet SDK, and clone this repo to see how it behaves in a vanilla environment.

It is sorta re-assuring that it does work somewhere.

[DustinCampbell]

Could you share your OmniSharp Log from one of those systems? Just open the project, wait for OmniSharp to finish loading (i.e. the "run/debug test" adornments appear) and click "debug test". Provide the log after the error appears.

[StephenRedd]

I attached the log for one in the above comment, but I'll get some more logs for you from the other systems and projects too.

[DustinCampbell]

Sorry, I missed that. It doesn't look it hit the failure in your log.

Out of curiosity, have you tried waiting a bit longer? There are a couple of things that happen under the hood (for which there's no currently UI feedback) which might take awhile before the debugger spins up. Most importantly, it builds the project, which might take awhile.

[DustinCampbell]

If it's still spinning up the debug session and you click the "debug test" annotation again (#1421), it would explain why you get that error.

[StephenRedd]

I'll test waiting a while before trying to launch the test as well and capture the log, but generally speaking I have waited a while. If you take that log above, wait on the same system for 5 minutes, then click debug again here is what the next messages will look like:

[fail]: Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware
        An unhandled exception has occurred: Debug session already started.
System.InvalidOperationException: Debug session already started.
   at OmniSharp.DotNetTest.DebugSessionManager.VerifySession(Boolean isStarted)
   at OmniSharp.DotNetTest.DebugSessionManager.StartSession(TestManager testManager)
   at OmniSharp.DotNetTest.Services.DebugTestService.Handle(DebugTestGetStartInfoRequest request)
   at OmniSharp.Middleware.Endpoint.EndpointHandler`2.<HandleSingleRequest>d__18.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at OmniSharp.Middleware.Endpoint.EndpointHandler`2.<Process>d__16.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at OmniSharp.Middleware.EndpointMiddleware.<Invoke>d__7.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware.<Invoke>d__6.MoveNext()
[info]: OmniSharp.Middleware.LoggingMiddleware
        /v2/debugtest/getstartinfo: 500 6112ms
[info]: OmniSharp.DotNetTest.VSTestManager
        read: {"MessageType":"TestSession.Connected","Payload":null}
[info]: OmniSharp.DotNetTest.VSTestManager
        read: {"MessageType":"ProtocolVersion","Payload":1}
[fail]: OmniSharp.DotNetTest.DebugSessionManager
        Debug session not started.

[DustinCampbell]

Yeah, so something's failing before the debug session kicks off. 5 minutes is a pretty long time.

I'm going to planning to push out the first beta of our 1.10 release later today, which should have more reporting during that time when you're just waiting. Hopefully that will reveal something.

[ghost]

I'm seeing the same issue as @StephenRedd when I debug a second time. This occurs only a couple seconds after I click the CodeLens link.

[fail]: OmniSharp.DotNetTest.DebugSessionManager
        Debug session not started.
[fail]: Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware
        An unhandled exception has occurred: Debug session already started.
System.InvalidOperationException: Debug session already started.
  at OmniSharp.DotNetTest.DebugSessionManager.VerifySession (System.Boolean isStarted) [0x00055] in <7124f501081e464b97067a98f0b0e806>:0 
  at OmniSharp.DotNetTest.DebugSessionManager.StartSession (OmniSharp.DotNetTest.TestManager testManager) [0x00011] in <7124f501081e464b97067a98f0b0e806>:0 
  at OmniSharp.DotNetTest.Services.DebugTestService.Handle (OmniSharp.DotNetTest.Models.DebugTestGetStartInfoRequest request) [0x0000d] in <7124f501081e464b97067a98f0b0e806>:0 
  at OmniSharp.Middleware.Endpoint.Exports.RequestHandlerExportHandler`2[TRequest,TResponse].Handle (TRequest request) [0x00000] in <30afbacdd97f44c59c542cdbc3e6fa9a>:0 
  at OmniSharp.Middleware.Endpoint.EndpointHandler`2+<HandleSingleRequest>d__18[TRequest,TResponse].MoveNext () [0x00092] in <30afbacdd97f44c59c542cdbc3e6fa9a>:0 
--- End of stack trace from previous location where exception was thrown ---
  at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x0000c] in <12e050e5b3d34326a1b4e2e7624e75da>:0 
  at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Threading.Tasks.Task task) [0x0004e] in <12e050e5b3d34326a1b4e2e7624e75da>:0 
  at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Threading.Tasks.Task task) [0x0002e] in <12e050e5b3d34326a1b4e2e7624e75da>:0 
  at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd (System.Threading.Tasks.Task task) [0x0000b] in <12e050e5b3d34326a1b4e2e7624e75da>:0 
  at System.Runtime.CompilerServices.TaskAwaiter`1[TResult].GetResult () [0x00000] in <12e050e5b3d34326a1b4e2e7624e75da>:0 
  at OmniSharp.Middleware.Endpoint.EndpointHandler`2+<Process>d__16[TRequest,TResponse].MoveNext () [0x0025e] in <30afbacdd97f44c59c542cdbc3e6fa9a>:0 
--- End of stack trace from previous location where exception was thrown ---
  at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x0000c] in <12e050e5b3d34326a1b4e2e7624e75da>:0 
  at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Threading.Tasks.Task task) [0x0004e] in <12e050e5b3d34326a1b4e2e7624e75da>:0 
  at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Threading.Tasks.Task task) [0x0002e] in <12e050e5b3d34326a1b4e2e7624e75da>:0 
  at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd (System.Threading.Tasks.Task task) [0x0000b] in <12e050e5b3d34326a1b4e2e7624e75da>:0 
  at System.Runtime.CompilerServices.TaskAwaiter`1[TResult].GetResult () [0x00000] in <12e050e5b3d34326a1b4e2e7624e75da>:0 
  at OmniSharp.Middleware.EndpointMiddleware+<Invoke>d__7.MoveNext () [0x000d8] in <30afbacdd97f44c59c542cdbc3e6fa9a>:0 
--- End of stack trace from previous location where exception was thrown ---
  at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x0000c] in <12e050e5b3d34326a1b4e2e7624e75da>:0 
  at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Threading.Tasks.Task task) [0x0004e] in <12e050e5b3d34326a1b4e2e7624e75da>:0 
  at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Threading.Tasks.Task task) [0x0002e] in <12e050e5b3d34326a1b4e2e7624e75da>:0 
  at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd (System.Threading.Tasks.Task task) [0x0000b] in <12e050e5b3d34326a1b4e2e7624e75da>:0 
  at System.Runtime.CompilerServices.TaskAwaiter.GetResult () [0x00000] in <12e050e5b3d34326a1b4e2e7624e75da>:0 
  at Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware+<Invoke>d__6.MoveNext () [0x00080] in <54abb6e5c34d41e5b18eb3ce35092c5b>:0 
[info]: OmniSharp.Middleware.LoggingMiddleware
        /v2/debugtest/getstartinfo: 500 7686ms

[DustinCampbell]

OK. Yeah, I expected that you're both seeing this on the second click. The problem is figuring out what happened between the first and second click that caused the debugger not to spin up.

[StephenRedd]

@DustinCampbell I can't help but notice that you've been buzy, and there's a LOT of new code in both this and the roslyn projects... I have to wonder if you fixed it by accident with some of that new stuff? Anyway, you drop a new vsix for 1.10.0 and I'll be happy to test it out :) In the meantime, I'll run a few more tests and let you know how it goes.

[DustinCampbell]

I don't think I fixed it by accident, but I'd be happy if that were the case. 😄

[DustinCampbell]

Unfortunately, the project you provided doesn't build. It has the following error:

TagTests.cs(20,63): error CS0311: The type 'Covalence.Authentication.ApplicationDbContext' cannot be used as type parameter 'TContext' in the generic type or method 'DbContextOptions<TContext>'. There is no implicit reference conversion from 'Covalence.Authentication.ApplicationDbContext' to 'Microsoft.EntityFrameworkCore.DbContext'. [C:\Projects\covalence-api\test\test.csproj]
TagTests.cs(20,63): error CS0012: The type 'IdentityDbContext<>' is defined in an assembly that is not referenced. You must add a reference to assembly 'Microsoft.AspNetCore.Identity.EntityFrameworkCore, Version=1.1.1.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. [C:\Projects\covalence-api\test\test.csproj]

That said, it doesn't look like this project is set up to work 'dotnet test' as the Microsoft.NET.Test.Sdk package isn't referenced. It looks like you're using it with 'dotnet xunit' instead, which is not something we support.

[ghost]

That's very odd - builds on my system and I have no pending changes. I'll have to dig into that. (I assume you did a dotnet restore)

Oh, I see. I'm able to call dotnet test, but it must just be passing it through to xunit?

[DustinCampbell]

Trying a little harder got it building. 😄

[DustinCampbell]

OK. I can repro.

[DustinCampbell]

FWIW, the problem with building may be related to me having a different .NET Core SDK installed.

[DustinCampbell]

OK. So, here's what I'm seeing. Please let me know if this is similar to what you see:

1. I open the folder in VS Code and once OmniSharp finishes loading, there's a message that pops up to restore the project.

2. If I click "restore", it runs a dotnet restore but there's an error message in the restore output:

   Errors in c:\Projects\covalence-api\test\test.csproj
       Unable to resolve 'c:\Projects\covalence-api\src\Covalence.API\Covalence.API.csproj' for '.NETCoreApp,Version=v1.1'.
   

3. At this point, I click "debug test" and I get the error you described.

Next I tried the following:

1. Run dotnet restore at the command line, which finishes without errors. (curious)
2. Open the folder in VS Code again and allow OmniSharp to finish loading.
3. When the restore popup appears, don't click anything. Instead, you can press Esc to dismiss it.
4. Without clicking "restore" on that prompt, click "debug test"
5. The debugger fires up and the breakpoint hits.

IOW, what I'm seeing is that the dotnet restore inside VS Code seems to be breaking the project, though I'm not 100% sure why. Honestly, I'm not sure why the prompt is happening at all. That feels like a bug.

Do you see similar behavior?

[ghost]

Similar, but not identical.

Whenever I open the project, it asks me to restore (not sure why, it's super annoying). If I don't restore, I still won't hit breakpoints, but it will try to load the debugger at least.

[DustinCampbell]

I see why the restore prompt is happening. It's because OmniSharp has a case-sensitive match between the package reference and the package dependency. In test.csproj, try changing "Microsoft.testplatform.testhost" to "Microsoft.TestPlatform.TestHost".

[DustinCampbell]

Here it is working on my Windows box as proof that it can work. 😄

I'll try my Mac tomorrow.

[ghost]

I'm still getting the same "Debug adapter process has terminated unexpectedly" message, but at least it doesn't try to restore each load! So thanks for that.

[DustinCampbell]

Here's the fix for that package restore issue: OmniSharp/omnisharp-roslyn#861.

[gregg-miskelly]

@fedoranimus the "Debug adapter process has terminated unexpectedly" is going to be something different. Can you try installing the 1.10-beta2 release (instructions), setting the "csharp.unitTestDebugingOptions" option (in Preferences->Options) to have debugger logging enabled, and then tell me the last bit of what you see in the debug console?

[gregg-miskelly]

@fedoranimus actually, before you do that, is there anything in crashreporter for vsdbg-ui?

[ghost]

I am seeing crash reports for vsdbg-ui now.

Process:               vsdbg-ui [50855]
Path:                  /Users/USER/*/vsdbg-ui
Identifier:            vsdbg-ui
30  vsdbg-ui                      	0x000000010ec5fb21 run(int, char const**) + 2081
31  vsdbg-ui                      	0x000000010ec5fc5e main + 158
       0x10ec54000 -        0x10ec70fff +vsdbg-ui (0) <FE919E55-60F5-32B6-93FC-31DDA0A316B0> /Users/USER/*/vsdbg-ui

Edit: Have not yet updated to 1.10-beta2

[ghost]

Updated to 1.10-beta2. I'm still seeing the same issues.

Here is my vsdbg-ui.log

[gregg-miskelly]

@fedoranimus can you send me a bit more of the crash report?

[DustinCampbell]

@gregg-miskelly: I can repro this issue on my Mac. I did the following:

1. Downloaded and installed the latest .NET Core 2.0 SDK from https://dotnetcli.blob.core.windows.net/dotnet/Sdk/release/2.0.0/dotnet-dev-osx-x64.latest.pkg.
2. Cloned the project that @fedoranimus provided from https://github.com/fedoranimus/covalence-api
3. Ran dotnet restore in the covalence-api folder that I just cloned.
4. Typed code . to open the covalence-api folder in VS Code.
5. Opened test/AccountControllerIntegrationTests.cs in VS Code and waited for OmniSharp to finish loading (and the CodeLens adornments to appear).
6. Set a breakpoint in CreateAccount and clicked debug test

Shortly after the debugger starts up, I got the "Debug adapter process has terminated unexpectedly" message.

[DustinCampbell]

Here's the crash log. It looks similar to the heap corruption bug you already looked at.

vsdbg-ui_2017-05-17-100155_Dustins-MacBook-Pro.crash.zip

[gregg-miskelly]

Sorry if this is obvious, but I wrote up some instructions: https://github.com/OmniSharp/omnisharp-vscode/wiki/Diagnosting-%22Debug-adapter-process-has-terminated-unexpectedly%22

[EDIT]: please disregard since Dustin provided the crash report, and anyway the repro project reproduced the crash for Dustin anyway.

[gregg-miskelly]

@DustinCampbell Thanks! Sorry, I thought you couldn't repro the crash Dustin.

[DustinCampbell]

@DustinCampbell Thanks! Sorry, I thought you couldn't repro the crash Dustin.

It works great on Windows, but I hadn't tried it on my Mac yet.

[gregg-miskelly]

Yup, this is a dupe of #1456. Looks like whatever has embedded symbols isn't in your project. I can build privates so you can work around. But unfortunately our lab infrastructure is all down right now. So I am not sure how long that will take.

[ghost]

Okay, thank you. Sorry, I was away from my system all day.

[DustinCampbell]

It's OK. Thank you for providing that simple project to help us repro. Hopefully we'll be able to get you some private bits to try.

[DustinCampbell]

@fedoranimus: I'm curious to know if the latest update (1.10) fixed the issue for you.

[ghost]

Yes, it does, thank you!

[DustinCampbell]

Excellent! Thanks for confirming. It took a bit to get to the bottom of it, but I think this issue is now fixed.