Sdk: dotnet restore/dotnet run in the 1.0 CLI fail with a segmentation fault on debian stretch

[mlorbetske]

_From @livarcocc on April 14, 2017 20:21_

_From @harindu95 on March 26, 2017 2:25_

Steps to reproduce

I tried the following method from official site.

 sudo apt-get install curl libunwind8 gettext
 curl -sSL -o dotnet.tar.gz https://go.microsoft.com/fwlink/?linkid=843453
 sudo mkdir -p /opt/dotnet && sudo tar zxf dotnet.tar.gz -C /opt/dotnet
 sudo ln -s /opt/dotnet/dotnet /usr/local/bin
 dotnet new console -o hwapp

Expected behavior

Creating a new project

Actual behavior

Crashed with the following error

 Error reading JObject from JsonReader. Path '', line 0, position 0.
 at Newtonsoft.Json.Linq.JObject.Load(JsonReader reader, JsonLoadSettings settings)
 at Newtonsoft.Json.Linq.JObject.Parse(String json, JsonLoadSettings settings)
 at Newtonsoft.Json.Linq.JObject.Parse(String json)
 at Microsoft.TemplateEngine.Edge.Settings.SettingsLoader.EnsureLoaded()
 at Microsoft.TemplateEngine.Edge.Settings.SettingsLoader.GetTemplates(HashSet`1 templates)
 at Microsoft.TemplateEngine.Edge.Template.TemplateCreator.List(Boolean exactMatchesOnly, Func`3[] filters)
 at Microsoft.TemplateEngine.Cli.New3Command.PerformCoreTemplateQueryAsync()
 at Microsoft.TemplateEngine.Cli.New3Command.<EnterTemplateManipulationFlowAsync>d__65.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 System.Runtime.CompilerServices.ConfiguredTaskAwaitable`1.ConfiguredTaskAwaiter.GetResult()
 at Microsoft.TemplateEngine.Cli.New3Command.<ExecuteAsync>d__66.MoveNext(\'

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:     debian
OS Version:  9
OS Platform: Linux
RID:         debian.8-x64
Base Path:   /opt/dotnet/sdk/1.0.1

find /opt/dotnet -name '*.so' -type f -print | xargs ldd | grep 'not found'

liblldb-3.6.so => not found
liblldb-3.6.so => not found

_Copied from original issue: dotnet/cli#6153_

_Copied from original issue: dotnet/templating#589_

[mlorbetske]

_From @livarcocc on April 14, 2017 20:21_

_From @ofmendez on April 14, 2017 20:19_

Same here, exact result :(

[mlorbetske]

@ofmendez @harindu95 can you try running dotnet new --debug:reinit please?

[mlorbetske]

_From @ofmendez on April 15, 2017 4:17_

@mlorbetske
Although the comand
find /opt/dotnet -name '*.so' -type f -print | xargs ldd | grep 'not found'
now get empty message...
I resumed the method from official site:

dotnet new console -o hwapp
cd hwapp
dotnet restore

and in this point I get:

[1] 18747 segmentation fault dotnet restore

I tried with other names and sequences, like in the official video tutorial:

dotnet new console -o myapp
cd myapp
code .

And run dotnet restore in the built-in terminal of VScode, getting the same result :(

[mlorbetske]

@ofmendez I'm not sure what the first command you mentioned is supposed to do to be honest, my Linux command line skills are rusty at best. From the sound of it though, the "new" command has produced a csproj & related artifacts in the specified folder - if that's correct & you're now facing an issue with dotnet restore, I think this issue should move back to dotnet/cli.

/cc @livarcocc

[mlorbetske]

@ofmendez did I interpret the state of things correctly? If so, we should get the restore issue looked at by moving the issue to the dotnet/cli or nuget/home repos

[mlorbetske]

_From @JacsonF on May 3, 2017 23:6_

@mlorbetske
Thank you for the solution.

[mlorbetske]

_From @Yutsa on May 6, 2017 14:4_

I followed @mlorbetske instructions and I have the same issue as @ofmendez when trying to do dotnet restore or dotnet run it segfaults.

I guess Stretch isn't supported yet unfortunately. I hope I'll find a way to use dotnet core on my Debian Stretch soon though.

[mlorbetske]

Thanks for the clarification. I'll move this back to the CLI repo for further investigation.

[Yutsa]

I guess a VM running Debian Jessie will be needed if I want to develop with .NET core for now, but the point of dotnet core was to avoid using a VM to do .NET development

[livarcocc]

I don't believe the 1.0 CLI supports this distro.

@eerhardt to confirm.

[Yutsa]

@livarcocc Will the next version support it ? Is it possible at all to use .NET Core on Stretch now ?

[livarcocc]

For 2.0, we have a linux portable distribution that may work on Stretch. That really depends on the runtime. You can give that a try.

[eerhardt]

For 1.0, we only officially supported Debian 8.2. For .NET Core 2.0, we are officially supporting Debian 8.7+.

See https://github.com/dotnet/core/blob/master/roadmap.md#supported-os-versions

@Yutsa - you can try .NET Core SDK 2.0 by downloading a daily build from https://github.com/dotnet/cli/tree/release/2.0.0#installers-and-binaries and choosing the Linux x64 row: https://dotnetcli.blob.core.windows.net/dotnet/Sdk/release/2.0.0/dotnet-dev-linux-x64.latest.tar.gz

[Yutsa]

I actually managed to use .NET Core 1.0 on Stretch using some Jessie package.

I have detailed it here.

I guess I'll try 2.0 when it'll be released.

[livarcocc]

Closing this issue since we haven't seen the crash in a while. We can re-activate if it happens again.