coreclr doesn't build on linux 4.6 and newer #6714
Comments
|
I just tried to build the coreclr repo on my fedora box. It is also segfaulting. when generating version.cpp with skipgenerateversion, later when building the managed components |
tmds
changed the title
|
@tmds I have all of a sudden started to hit a segfault on one of my VMs with Ubuntu 14.04 too. So I went to investigate the issue, but after several attempt where I was hitting the issue running under the lldb, the restore passed and now issue went away and I cannot repro it anymore even after deleting Tools and packages folders. I will try to repro it some way again. |
|
This repro was with the older tools 1.0.0-rc3-002733. I have synced my VM to the latest sources, now the tools used are 1.0.0-preview3-003223, but I can still repro the crash. The call stack is different now though and seems to happen at random places. |
|
I am using a 4.7.3 kernel. |
|
@livarcocc When does CLI pickup LTS of SharedFW? |
|
@janvorli behavior matches the referenced issue, after setting COMPlus_INTERNAL_ThreadSuspendInjection to zero dotnet is no longer crashing |
|
|
@livarcocc -- could chime in on this issue? It's blocking customers using the C# extension for VS Code with an updated kernel. |
|
@gkhanna79 The CLI has picked up the official 1.0.1 of the shared framework almost a month ago in this PR: dotnet/cli@8d7dd39. We picked up M.NC.App 1.0.1 and we updated the host to 1.0.4. |
|
What is the build of CLI in question that results in the crash? As @janvorli called out, the build he was working with didnt have the fix. It will be good to understand the versions of the involved components as a starting point. |
|
My coreclr master branch build has the same version as mentioned by @janvorli The OmniSharp vscode plugin has this version Both stop crashing when COMPlus_INTERNAL_ThreadSuspendInjection is set to zero. |
|
cc @piotrpMSFT as well |
|
The commit hash mentioned above maps to dotnet/core-setup@cee57bf, which is pre-RTM timeframe (and thus, likely corresponds to the RTM build) and thus, definitely does not correspond to https://github.com/dotnet/core-setup/releases/tag/v1.0.1 when we snapped the build containing the fix for Linux kernel. @tmds If you set COREHOST_TRACE environment variable to 1, you will get a trace log of where binaries are being loaded from. Can you please share the log and also share the build information of libcoreclr.so? |
|
@gkhanna79 how can I retrieve the build information of libcoreclr.so? COREHOST_TRACE: |
|
@tmds - you can run That should get an information in a format like this: |
|
coreclr Tools and OmniSharp have the same version for libcoreclr.so: |
|
@tmds According to the trace, libcoreclr.so is being loaded from the following location:
Do you have a Microsoft.NETCore.App/1.0.1 folder, next to the 1.0.0 above? Also, please share the trace for "dotnet ". |
|
There is only a 1.0.0 folder, no 1.0.1 folder. COREHOST_TRACE for dotnet: https://gist.githubusercontent.com/tmds/f12cc75b82c5ca52c518852b240b637f/raw/5bba16868d399dce133827d829a90ba391ecb8c5/dotnet |
|
So OmniSharp and coreclr Tools are crashing because they are using 1.0.0. When they use 1.0.1 they shouldn't crash anymore. my dotnet install (from https://download.microsoft.com/download/1/5/2/1523EBE1-3764-4328-8961-D1BD8ECA9295/dotnet-dev-fedora.23-x64.1.0.0-preview2-003131.tar.gz) the coreclr Tools install (from https://dotnetcli.blob.core.windows.net/dotnet/Sdk/1.0.0-preview3-003223/dotnet-dev-fedora.23-x64.1.0.0-preview3-003223.tar.gz) |
|
The second trace shows libcoreclr.so is being loaded from 1.0.1 folder:
This is correct. Since the installer for .NET Core SDK (aka CLI) version 3223 is installing 1.0.0, I suspect you are running into the issue fixed in 1.0.1. This is inline with observation made by @janvorli in https://github.com/dotnet/coreclr/issues/7345#issuecomment-249576324 that 3223 does not have the fix. @livarcocc PTAL to get this fixed in the upcoming Preview2 release of CLI. |
|
CC @leecow @piotrpMSFT |
|
It's a little hard to follow the discussion, but it sounds like this issue is fixed but newer versions of the Preview3 versions of the .NET Core SDK don't install it? OmniSharp has been updated (OmniSharp/omnisharp-roslyn@a607e7d) but the C# extension for VS Code hasn't been updated to take a new version of it yet. |
It looks like preview2(-003131) has the correct version and preview3(-003223) is using the older version. |
|
If this is the segfault introduced with kernel 4.6.2 then updating to the 1.0.1 shared framework will take care of things. Links to tarballs:
|
|
@leecow: note that it appears that preview3 still exhibits the issue. |
|
preview3 003223 is quite an old build. Latest preview3 build in CLI repo is 3748. Perhaps you can try installing latest from https://github.com/dotnet/cli? I'm also curious if we are advertising preview3 installers on any properties. How did preview3 get into this conversation? |
|
@piotrpMSFT this is the version @janvorli and I got in the Tools folder when building the coreclr repo |
|
Can you try bumping the dependency to 3748 or later? |
|
I changed coreclr doesn't build. Made a change to init-tools.sh: Managed components fail: There is a |
|
@tmds Can you try to delete the whole Tools and packages directories and retry? Maybe there is something stale in there. |
|
@janvorli I cleaned up my working copy before the build. If you give it a try, you should get similar build errors. |
|
@tmds I can confirm this version of tools doesn't work for me either on my Ubuntu 14.04. Actually, early at the beginning, I am getting this error: But the native build starts running after that, so I wonder if you have the same and just haven't noticed this first error that I guess causes the 2nd. |
|
@piotrpMSFT - I have just tried the 1.0.0-preview3-003748 and the init-tools.sh fail with that. I have tried the latest 1.0.0-preview3-003786 and it fails too. But |
tmds
changed the title
tmds
changed the title
|
DotnetCLIVersion.txt on master is still pointing to a dotnet version that Op ma 31 okt. 2016 om 18:38 schreef Gaurav Khanna <[email protected]
|
|
@livarcocc @mellinoe What version should be used that contains the required fix? |
|
@gkhanna79 @tmds what version of coreclr added the fix? I'll see when that got incorporated. |
|
Can we just update everything to use the stable CLI coming out of the preview2.1 branch? It's running on the 1.1 RTM shared framework and works on all the distros we care about. Except for Alpine, but we will need to copy that bootstrap version over regardless of what version we choose. |
|
I think that's the right call @mellinoe. The latest from preview3 dropped PJ support which would likely not play well in coreclr repo at the moment. |
|
@piotrpMSFT @livarcocc What are the next steps here? |
|
@piotrpMSFT @livarcocc ? |
|
If I read this right, huge thread, this seems to have been a problem on the preview2-1 CLI, which we don't support anymore. When we shipped 1.0 CLI, it was already depending on the latest runtime, and current CLI out there, 1.0.4, depends on 1.0.5 and 1.1.2 of the CLI. And 2.0 CLI depends on 2.0 runtime. What else is there to be done by the CLI here? |
|
@livarcocc I assume this is all fixed by now. |
ghost
locked as resolved and limited conversation to collaborators
OmniSharp is crashing on my freshly installed fedora 23 system. Investigating the issue suggest the crash is somewhere more 'lowlevel' in the stack. See dotnet/vscode-csharp#773.
The issue might not easily reproduce on a VM. On my native install the crash happens soon after I start using intellisense in vscode. Two coredumps show a segmentation fault below
Thread::RareDisablePreemptiveGC.The text was updated successfully, but these errors were encountered: