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

[rytido]

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()

[JRahnama]

@rytido thanks for bringing this up. Using UID and PWD will solve the issue.

open System
open Microsoft.Data.SqlClient

let connectionString = "Data Source=127.0.0.1;UID=<user name>;PWD=<password>;"
let cnxn = new SqlConnection(connectionString)
exception Error1 of string
try
cnxn.Open()
Console.WriteLine(cnxn.State)
cnxn.Close()
Console.WriteLine(cnxn.State)
with
| Error1(str) -> printfn "Error1 %s" str

[rytido]

Did Kerberos auth support get dropped? I cannot necessarily use sql server auth. This worked in net5.0.

[JRahnama]

@rytido I will test with Kerberos and will update you soon.

[JRahnama]

something to mention here about a breaking change on net 6 and kerberos . Port has been removed from SPN for Kerberos and Negotiate. I made a C# application with net 6 and kerberos and got the same results as yours. F# acted the same. When I used user name and password everything worked fine.

[rytido]

That's not the issue for two reasons:

1. If I revert to netcoreapp3.1 my app works, and that doc indicates 3.x behavior should be the same as 6.
2. 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.

[stcpottdav]

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]

[JRahnama]

@roji have you seen similar issue with net 6 and Kerberos? I have tested with Microsoft.Data.SqlClient and System.Data.SqlClient using Kerberos authentication. Tested with C# and F# no exception is thrown. It just does not work, no results come back and it gets terminated. The documentation suggests adding a switch will fix the issue. I tested with the switch and environment variable, no luck so far. Just wanted to check with you.

Thank you.

[rytido]

May also be worth noting that in an AspNetCore app this doesn't just make a single request fail, it silently kills the whole service.

[wfurt]

I think this is dup of dotnet/runtime#60906. The linked breaking change only impact HttpClient in cases it tries to generate SPN on it's own.

[wfurt]

BTW it may be best (fastest) to update SqlClient to react to dotnet/runtime#55037.

[JRahnama]

thanks @wfurt. Although the issue seems external according to the link you posted. I'll do more debugging to see why no exception is thrown

[wfurt]

for runtime, we call EnsureGssInitialized via static constructor. That will load all the function pointers. AFAIK SqlClient does not do it so it would crash (dereferencing NULL in gssapi code) when trying to use the functions. If you call NetSecurityNative_EnsureGssInitialized once, the crash should go away. Let me know if that make sense @JRahnama.

[JRahnama]

@wfurt thanks for the update. I added the EnsureGssInitialized to SqlClient and it worked for net 6 and failed for net 5. Just to confirm this is expected correct? I mean that part of the code is only for net 6 and after if I am not mistaken.

[wfurt]

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.