runtime: SIGSEGV crash at x64 linux alpine-net6 docker in NetSecurityNative_ImportPrincipalName
Description
My app crashes with SIGSEGV on net6.0-rc2. shortly after start without any stderr messages. Stack trace shows reason deep in native runtime code
Actual behavior
gdb trace
#0 0x00007f3ce7cbb3fc in NetSecurityNative_ImportPrincipalName () from /usr/share/dotnet/shared/Microsoft.NETCore.App/6.0.0-rc.2.21480.5/libSystem.Net.Security.Native.so
#1 0x00007f3e31d27b6a in ?? ()
#2 0x6376534c5153534d in ?? ()
#3 0x7665642d6c71732f in ?? ()
#4 0x3a7275746e6f6b2e in ?? ()
#5 0x0000000033333431 in ?? ()
#6 0xffffffffffffffff in ?? ()
#7 0x00007f3ea8caac7b in ?? () from /usr/share/dotnet/shared/Microsoft.NETCore.App/6.0.0-rc.2.21480.5/libcoreclr.so
#8 0x00007f3e31d27579 in ?? ()
#9 0x00007f3ceee31180 in ?? ()
#10 0x0000001ce7d2ac28 in ?? ()
#11 0x00007f3cee82b708 in ?? ()
#12 0x0000000000000000 in ?? ()
strace tail
open("/usr/share/dotnet/shared/Microsoft.NETCore.App/6.0.0-rc.2.21480.5/System.Net.Security.Native.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/app/runtimes/unix/lib/netcoreapp2.1/System.Net.Security.Native.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/lib/System.Net.Security.Native.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/local/lib/System.Net.Security.Native.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/System.Net.Security.Native.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/share/dotnet/shared/Microsoft.NETCore.App/6.0.0-rc.2.21480.5/libSystem.Net.Security.Native.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 228
fcntl(228, F_SETFD, FD_CLOEXEC) = 0
fstat(228, {st_mode=S_IFREG|0755, st_size=18480, ...}) = 0
read(228, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\20\0\0\0\0\0\0"..., 960) = 960
mmap(NULL, 24576, PROT_READ, MAP_PRIVATE, 228, 0) = 0x7f4461e88000
mmap(0x7f4461e89000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 228, 0x1000) = 0x7f4461e89000
mmap(0x7f4461e8b000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED, 228, 0x3000) = 0x7f4461e8b000
mmap(0x7f4461e8c000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 228, 0x3000) = 0x7f4461e8c000
close(228) = 0
mprotect(0x7f4461e8c000, 4096, PROT_READ) = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=NULL} ---
rt_sigprocmask(SIG_UNBLOCK, [RT_3], NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [SEGV], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [RT_3], NULL, 8) = 0
rt_sigaction(SIGSEGV, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f4623717c8b}, NULL, 8) = 0
unlink("/tmp/clr-debug-pipe-155-5215008-in") = 0
unlink("/tmp/clr-debug-pipe-155-5215008-out") = 0
unlink("/tmp/dotnet-diagnostic-155-5215008-socket") = 0
rt_sigreturn({mask=[]}) = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=NULL} ---
+++ killed by SIGSEGV (core dumped) +++
Regression?
works on net5 alpline docker flawlessly
on win-x64 works fine with net5 or net6-rc2 runtime
Known Workarounds
No response
Configuration
dotnet --info
Host (useful for support):
Version: 6.0.0-rc.2.21480.5
Commit: 6b11d64e7e
.NET SDKs installed:
No SDKs were found.
.NET runtimes installed:
Microsoft.AspNetCore.App 6.0.0-rc.2.21480.10 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.0-rc.2.21480.5 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
Other information
No response
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 20
- Comments: 29 (18 by maintainers)
Note we’ve missed the cutoff for 6.0.1. The 6.0.2 patch won’t go out in Feb which is a long time away. So a fix like [1] in SqlClient might be ideal, even if temporary, as we can push that package separately.
cc @ajcvickers in case it is relevant to him.
Spent the day yesterday debugging the exact same issue, connecting to a Kerberos-enabled MSSQL server in a docker container, using Microsoft’s .NET 6.0 base image (
mcr.microsoft.com/dotnet/sdk:6.0). We did find a workaround until the issue is resolved: making a Kerberised HTTP call prior to connecting to SQL Server fixes the issue:FWIW, I’ve hit the same bug when attempting to authenticate with Kerberos to a MSSQL server. I’ve posted a simple reproduction here: https://gist.github.com/trexx/63bcb7e5a81fffce502a65c86bd77c55 Works when built against dotnet5.0. Switching to username and password auth bypasses the crash in dotnet6.0.
https://github.com/dotnet/runtime/commit/3a66ebf408fd403ff7a272afb2fdc00b1ad8114e is not in .NET 6.0 RC2 (will only be in 7.0)
On Unix, UTF-8 is the default for string marshalling, so it would have been marshalling as UTF-8 before the change too.