dotnet build intermittently exits with Segmentation fault (core dumped) or 139 on linux

[ramsubbaraoc]

I am using dotnet core sdk 2.1.403 and building projects on linux. Intermittently the build fails with either Segmentation fault or with 139

The build itself doesn't start, as soon as the command "dotnet build" is issued it comes out with "Segmentation fault (core dumped)" or with 139.

The platform that i am using is
RedHatEnterpriseServer 7.3
Linux2x86_64

Please can someone provide some insights into this.

The content of the project file is

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.1</TargetFramework>
    <GenerateAssemblyInfo>false</GenerateAssemblyInfo>
    <AppendTargetFrameworkToOutputPath>false</AppendTargetFrameworkToOutputPath>
    <OutputPath>$(BROOT)/bin</OutputPath>
    <AssemblyName>Simple</AssemblyName>
    <IntermediateOutputPath>$(OutputPath)</IntermediateOutputPath>
    <OutDir>$(OutputPath)</OutDir>
  </PropertyGroup>
  <ItemGroup>
    <Reference Include="x">
      <HintPath>$(BROOT)/bin/x.dll</HintPath>
    </Reference>
  </ItemGroup>

  <Target Name="PostBuild" AfterTargets="PostBuildEvent" Condition="'$(OS)' == 'Windows_NT'">
   <Exec Command="rmdir /S /Q obj" />
  </Target>

  <Target Name="PostBuild" AfterTargets="PostBuildEvent" Condition="'$(OS)' != 'Windows_NT'">
   <Exec Command="rm -r obj" />
  </Target>

</Project>

Thanks

[scalablecory]

@livarcocc

[danmoseley]

1. can you minimise the repro? Eg., does this happen just building an empty new project?
2. do you have another machine with the same configuration you can try this on?
3. please try the 3.0 SDK. Does it repro? If not, is it feasible for you to upgrade to 3.0 (or 2.2) SDK? you should still be able to produce the same build results, but there are a huge number of fixes since 2.1 and this may make the problem go away.

If the above doesn't help, or you simply can't update your SDK, then you'll have to attempt to use the lldb debugger to get a stack trace that might hint at the issue. That will be more time consuming.

There are instructions for installing LLDB in this doc https://github.com/dotnet/corefx/blob/master/Documentation/debugging/unix-instructions.md

And for launching a process under LLDB in this doc
https://github.com/dotnet/coreclr/blob/master/Documentation/building/debugging-instructions.md#debugging-coreclr-on-linux-and-macos

This should hopefully run and stop at the point of failure. Then you can try to get a stack trace. This also may help:
https://kapeli.com/cheat_sheets/LLDB_Commands.docset/Contents/Resources/Documents/index

[ramsubbaraoc]

@danmosemsft Thanks for respoding.

I haven't tried with an empty project. Probably can give a try.
On upgrading the SDK, as of now it is not an option for us. Will try to capture some diagnostics and see if that helps or not.

In the mean time i had set the following env variables
export COMPlus_ReadyToRun=0
export COMPlus_ZapDisable=1
export COMPlus_EnableDiagnostics=0

Are they valid and are there any chances of resolving the issue?

[wfurt]

the variables impact how assemblies are loaded. I think key would be getting core file or getting this fail under debugger. (gdb or lldb) Also watch for any pinvokes by your code or linked packages.

[wfurt]

do you have any update @ramsubbaraoc?
cc: @tmds

[ramsubbaraoc]

I am working on collecting diagnostics,as it is intermittent would take time to recreate. Probably we can close this ticket for now.Once i have the diagnostics we can reopen it again

[tmds]

@ramsubbaraoc how did you install .NET Core on the rhel7 machine? Are you using the rh-dotnet21 package (https://dotnet.microsoft.com/download/linux-package-manager/rhel7/sdk-2.1.802)?

[ramsubbaraoc]

I am using binaries rather than installer. I took the binaries from the following locaiton
https://dotnet.microsoft.com/download/dotnet-core/2.1
and the version i am using is 2.1.403

[tmds]

Can you try using the rh-dotnet21 packages and see if you still get the issue?

[ramsubbaraoc]

Sure. I can give a try.

[ericstj]

@ramsubbaraoc are you still facing this issue?

[ViktorHofer]

Triage: Closing as we haven't heard back from @ramsubbaraoc.