SqlClient: Error code 139 when attempting Microsoft.Data.SqlClient connection on Linux with net6.0

I get error code 139 when attempting Microsoft.Data.SqlClient connection on Linux with net6.0 (6.0.100). I see the error when using dotnet watch run, otherwise it exits silently. The same code works on net5.0.

watch : Exited with error code 139

To reproduce

app.fsproj

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net6.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <Compile Include="Program.fs" />
  </ItemGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.Data.SqlClient" Version="3.0.1" />
  </ItemGroup>

</Project>

Program.fs

open System
open Microsoft.Data.SqlClient

let server = Environment.GetEnvironmentVariable("SERVER")
let connectionString = $"Server={server};Trusted_Connection=True;"

let cnxn = new SqlConnection(connectionString)

cnxn.Open() // program silently exits here (or with code 139 if using watch)
printf "connection is open"
cnxn.Close()

About this issue

Original URL
State: closed
Created 3 years ago
Reactions: 5
Comments: 56 (32 by maintainers)

Links to this issue

sql server - How can I get Kerberos authentication to work in a Docker Linux container hosting a .Net 6 application with a SqlConnnection? - Stack Overflow

Most upvoted comments

@stcpottdav we are planning a hotfix release around January 15 of 2022. The release will include some other fixes as well.

+15

JRahnama on Dec 8, 2021

I think this is dup of https://github.com/dotnet/runtime/issues/60906. The linked breaking change only impact HttpClient in cases it tries to generate SPN on it’s own.

wfurt on Nov 18, 2021

@Palsternakka Microsoft.EntityFrameworkCore.SqlServe is using M.D.SqlClient v2.1.4. Can you overwrite the version in the csproj file by adding packageReference to version 4.1? The issue was addressed first in v4.0.1 and is not back ported to previous versions yet.
<ItemGroup>
      <PackageReference Include="Microsoft.Data.SqlClient" Version="4.1.0" />
</ItemGroup>

This worked for me, thank you!

Palsternakka on Aug 8, 2022

@Palsternakka Microsoft.EntityFrameworkCore.SqlServe is using M.D.SqlClient v2.1.4. Can you overwrite the version in the csproj file by adding packageReference to version 4.1? The issue was addressed first in v4.0.1 and is not back ported to previous versions yet.

<ItemGroup>
      <PackageReference Include="Microsoft.Data.SqlClient" Version="4.1.0" />
</ItemGroup>

JRahnama on Aug 3, 2022

We have been getting this issue as well. Couldn’t use the assembly above since it’s all done through EF in the application, but we did get a temporary work around until the an official update that can replace the downstream nuget package.

Adding the EnsureGssInitialized() method call in the program.cs stopped the error.

    public class Program
    {        
        [DllImport("System.Net.Security.Native", EntryPoint = "NetSecurityNative_EnsureGssInitialized")]
        internal static extern int EnsureGssInitialized();
        
        public static void Main(string[] args)
        {
            if(OperatingSystem.IsLinux()) 
                EnsureGssInitialized();
                
            CreateHostBuilder(args).Build().Run();
        }

    // builder code etc...

    }

clbiggs on Dec 7, 2021

We are planning on a hotfix from our side sometime soon. Time will be announced soon.

JRahnama on Nov 26, 2021

I’ve been struggling trying to upgrade our .NET 5 API to .NET 6 with for days! We host our API on a Linux containers in Kubernetes. The container kept crashing and I saw that it threw a Segmentation fault (core dumped). error. Explicitly referencing Microsoft.Data.SqlClient 4.1.0 worked for me!

duyn9uyen on Jul 2, 2022

@ladeak as an alternative you can use this package with MDS 4

https://www.nuget.org/packages/ErikEJ.EntityFramework.SqlServer/

ErikEJ on Mar 10, 2022

I have run into the same issue. I have tested the suggested nuget package: Microsoft.Data.SqlClient version 4.1.0, and in .net6 + RHEL 8 I don’t get segfault anymore with EntityFrameworkCore.

However, using EntityFramework (the non-core version) version 6.4.4, I still face the issue. The workaround by @clbiggs seems to work there.

Should there be a bugfix in System.Data.SqlClient package too? (I believe that is being used by the classic EntityFramework)

ladeak on Mar 10, 2022

BTW, this would be for 6.0.4 to release in April. Meantime perhaps someone would like to explicitly paste in the code necessary to workaround, that was mentioned above, for the ease of others.

danmoseley on Feb 15, 2022

@JRahnama unfortunately I don’t have any possibility to test with MDS personally. Will ask a colleague tomorrow … he might have the necessary environment to test

aletsche on Nov 29, 2021

yes, this was done late (unfortunately) in 6.0. So either wrap it In try/catch or even better

if (Environment.Version.Major >= 6)
{
    EnsureGssInitialized();
}

Long run, I would like to add enough public surface so SqlClient (and others) do not need to depend on private functions. We missed 6.0.1 maintenance and next one will be early next year. If you can do anything faster it would be great @JRahnama. If there is new package available, please ping both threads so people can try it.

wfurt on Nov 19, 2021

I am having the same issue. After running a test, I used dmesg to show where the segmentation fault happened: dotnet[659]: segfault at 0 ip 00007fdc7e8a63bc sp 00007ffe5b10db70 error 4 in libSystem.Net.Security.Native.so[7fdc7e8a6000+1000]

stcpottdav on Nov 18, 2021

That’s not the issue for two reasons:

If I revert to netcoreapp3.1 my app works, and that doc indicates 3.x behavior should be the same as 6.
I set the env var DOTNET_SYSTEM_NET_HTTP_USEPORTINSPN=1, and just to be certain also set the context switch AppContext.SetSwitch("System.Net.Http.UsePortInSpn", true). The net6 version of this still crashes.

rytido on Nov 18, 2021