Nixpkgs: jetbrains.rider: debugger won't start for dotnet project

Created on 8 Feb 2019  ·  8Comments  ·  Source: NixOS/nixpkgs

Issue description

The rider gui prints "One or more errors occurred." when I attempt to start project binary in debug mode. The binary is not started.

Steps to reproduce

  1. Create .Net Core project from template.
  2. Put a breakpoint in code.
  3. Try to run it in debug mode.

Open Idea logs, notice the following in ~/.Rider2018.3/system/log/DebuggerWorker/JetBrains.Debugger.Worker.2019_2_08_10_35_13/

10:35:16.516 |V| DebugSessionFrontend          | Debugger worker MTA main thread:3 | Breakpoint /home/jdanek/projects/djObik-trigger/Program.cs, line 56 status changed: NotBound Not found associated module for breakpoint Program.cs:56,14
10:35:16.521 |V| DebugSessionFrontend          | Debugger worker MTA main thread:3 | Exception breakpoint added, exception System.Threading.ThreadAbortException
10:35:17.494 |V| CoreClrDebuggerUtil_Nojif     | :26                | Got CLR load callback from the debugger. The operation failed. The error code is CORDBG_E_DEBUG_COMPONENT_MISSING, or 0x80131C3C.
10:35:17.509 |V| CoreClrDebuggerUtil_Nojif     | Thread Pool Worker:24 | Done awaiting. Got CLR Callback? True! Timeout expired? False!
10:35:17.514 |V| DebugSessionFrontend          | Debugger worker MTA main thread:3 | Event from debugger: type TargetExited
10:35:17.701 |W| DebuggerWorker                | Debugger worker MTA main thread:3 | Failed to startup debugger. Fire terminating One or more errors occurred. CLR load callback is already in error state. The operation failed. The error code is CORDBG_E_DEBUG_COMPONENT_MISSING, or 0x80131C3C.

--- EXCEPTION #1/5 [COMException]
Message = “CLR load callback is already in error state. The operation failed. The error code is CORDBG_E_DEBUG_COMPONENT_MISSING, or 0x80131C3C.”
ExceptionPath.1 = Root.InnerException.InnerException.InnerException.InnerException
ExceptionPath.2 = Root.InnerException.InnerException.InnerExceptions.#0.InnerException
ExceptionPath.3 = Root.InnerException.InnerException.InnerException.InnerExceptions.#0
ExceptionPath.4 = Root.InnerException.InnerException.InnerExceptions.#0.InnerExceptions.#0
ClassName = System.Runtime.InteropServices.COMException
HResult = CORDBG_E_DEBUG_COMPONENT_MISSING=80131C3C
Source = JetBrains.Debugger.CorApi
StackTraceString = “at JetBrains.Debugger.CorApi.Pinvoke.CoreClrDebuggerUtil.RuntimeLoadCallback (System.Int32 hr, System.Void* pCordb, System.Threading.Tasks.TaskCompletionSource`1[TResult] taskWaitForStartup, System.Action`1[T] corDebugLoadhandler, System.UInt32 procId, JetBrains.Util.ILogger logger) [0x00014] in <3e14868adbae498dad98d2cd39c6659e>:0”

--- Outer ---

--- EXCEPTION #2/5 [AggregateException]
Message = “One or more errors occurred.”
ExceptionPath.1 = Root.InnerException.InnerException.InnerException
ExceptionPath.2 = Root.InnerException.InnerException.InnerExceptions.#0
[...]

Workaround

Start rider in a shell with

export LD_LIBRARY_PATH=/nix/store/l2yzllcn2injxx4qs21f2703ia56nqz8-dotnet-sdk-2.2.103/shared/Microsoft.NETCore.App/2.2.1/

in addition to that, I am also doing

export MSBuildExtensionsPath=/home/jdanek/Downloads/msbuild/Extensions

as a workaround for issue discussed on https://github.com/NixOS/nixpkgs/pull/43680 (still open). I downloaded that msbuild directory from mono project.

All 8 comments

Thanks for the workaround btw. This affects VS Code as well, and the same workaround applies.

Maybe we can package this workaround for now with rider, until we have a properly packaged msbuild. What do you think?

Possibly got fixed by upgrading dotnet-sdk. I now use version 2.2.401 from https://github.com/NixOS/nixpkgs/pull/66057 and debugger starts for me without the workaround.

Works for me on unstable with rider 2019.2.1

Thank you for your contributions.
This has been automatically marked as stale because it has had no activity for 180 days.
If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.
Here are suggestions that might help resolve this more quickly:

  1. Search for maintainers and people that previously touched the
    related code and @ mention them in a comment.
  2. Ask on the NixOS Discourse. 3. Ask on the #nixos channel on
    irc.freenode.net.

still not working for vscode

after some search, I now think my problem is related to https://github.com/OmniSharp/omnisharp-vscode/issues/3676
not related to nixos

Original issue seems to be solved, closing this one

Was this page helpful?
0 / 5 - 0 ratings

Related issues

retrry picture retrry  ·  3Comments

spacekitteh picture spacekitteh  ·  3Comments

sid-kap picture sid-kap  ·  3Comments

lverns picture lverns  ·  3Comments

copumpkin picture copumpkin  ·  3Comments