Segmentation fault error occurs while running EF core migration bundle in docker desktop on MacOS after migrating from ef core 6 to ef core 8

[nikjuice]

Hi,

I'm currently in the process of updating my project from .NET 6 to .NET 8, which involves migrating from EF Core 6 to EF Core 8. The project heavily relies on Docker containers.

I've provided the Dockerfile below, which is responsible for building the database:

`FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY //Here I copy project files

RUN dotnet tool install dotnet-ef --tool-path "./bin" --version 8.0.0
RUN ./bin/dotnet-ef migrations bundle --self-contained -r linux-x64 -o ./bin/efbundle

FROM mcr.microsoft.com/mssql/server:2022-CU8-ubuntu-20.04
ENV MSSQL_SA_PASSWORD=PASSWORD
ENV DB_NAME=DBNAME
ENV ACCEPT_EULA Y
ENV DOTNET_BUNDLE_EXTRACT_BASE_DIR=/var/tmp/bundle-extract
EXPOSE 1433

COPY --from=build PATH_TO_THE_PROJECT /var/tmp/

USER mssql
RUN ( /opt/mssql/bin/sqlservr & ) | grep -q "Recovery is complete"
&& ./var/tmp/efbundle --connection "Data Source=.;Initial Catalog=$DB_NAME;User Id=sa;Password=$MSSQL_SA_PASSWORD;Encrypt=False;"
&& pkill sqlservr
`
The project references are the following:

first after I changed SDK and EF core version, first I get the following error:

A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: TCP Provider, error: 35 - An internal exception was caught)
7.818 ---> System.Security.Authentication.AuthenticationException: The remote certificate was rejected by the provided RemoteCertificateValidationCallback.

To resolve this, I modified the connection string to have Encrypt=false (the same result was observed with TrustServerSertificate=true). However, this led to a new error: "Segmentation fault"

when I tried to disable rosetta, I got a bit different but similar error:

I asked collegue with windows machine to test this and it works there.

My setup is: MacOS sonoma 14.1 on m2 pro chip. Docker desktop 4.25.1 running with Rosetta emulation enabled.

Any insights or suggestions on resolving this issue would be greatly appreciated.

Thank you!

[ajcvickers]

Moving this to the SqlClient repo. See also Encrypt defaults to true for SQL Server connections.

[nikjuice]

Thanks, Arthur. Yeah, I saw that breaking change and that is why I have added Encrypt=false.

[nikjuice]

More details when I added --verbose to the bundle:

[nikjuice]

Just a tiny update - I just have tested this on mac with Intel I7 based chip (running ventura 13.6) and all works fine there.

[JRahnama]

@nikjuice so, is it confirmed that this is not SqlClient related issue?

[nikjuice]

@JRahnama I don't think it is confirmed. With my knowledge and result that I have it is hard to say is it SQLClient related or not. I suspect that it is something specific in core .net related to Linux implementation that is used by SQLClient.

[ajorkowski]

I am getting a similar issue, but in our case we are running a build server on Ubuntu (via Azure Devops), using Standard_F2s_v2 Azure virtual machines. This started to happen after we updated EF core to .net 8.

Here is how we generate the bundle:

dotnet tool install --global dotnet-ef
dotnet ef migrations bundle -p "..." --configuration Release -r linux-x64 -o $(Build.ArtifactStagingDirectory)/Migrations

And then we run it during release (on the same build environment). Note that we have always used the 'Encrypt=True' option in the connection string here:

./Migrations -- --connection "Server=...,1433;Initial Catalog=...;Encrypt=True;Connection Timeout=30;"

Here is the error we are seeing

2023-11-29T14:13:00.0872552Z ##[error]Bash exited with code '139'.
2023-11-29T14:13:00.0881833Z ##[error]Bash wrote one or more lines to the standard error stream.
2023-11-29T14:13:00.0888664Z ##[error]/agent/_work/_temp/cd21926e-7954-4a21-be9c-c2458442782e.sh: line 10:  4200 Segmentation fault

I tried it with the --verbose flag, but there are no additional logs - it seems to crash right away?

[Zaragor]

I was having a similar issue but on version 6. In my case Microsoft.EntityFrameworkCore.SqlServer 6.0.4 was depending on Microsoft.Data.SqlClient version 2.1.4, which has known problems with segfaults on linux machines (See here)

Adding an explicit dependency on Microsoft.Data.SqlClient for version 5.1.2 fixed the peer dependency for me, and removed the SegFault. I imagine anything >4.8.4 would work, but cannot verify that.

[ajorkowski]

@Zaragor Yes, I thought this might be the case, but the 8.0.0 version of Microsoft.EntityFrameworkCore.SqlServer has an implicit dependency to 5.1.1 of Microsoft.Data.SqlClient. I am somewhat worried that this problem has reappeared in dotnet 8 :/

Explicitly adding a dependency to 5.1.2 did not make a difference.

Here are some additional details about the build environment.
Base Image: Ubuntu2204 from Azure
dotnet SDK version: 8.0.100
dotnet-ef version: 8.0.0

[henrikwidlund]

We're also seeing this when running our application inside of Docker on a ARM Mac with Rosetta. Running the application outside of Docker works. Tried the same as @ajorkowski. I've got TrustServerCertificate=True. Also tried using the latest 6.0 packages of EF Core, but that didn't make a difference.

docker image: 8.0.100-1-bookworm-slim-amd64
dotnet SDK version: 8.0.100
dotnet-ef version: 8.0.0

[henrikwidlund]

This workaround worked for me: dotnet/runtime#94909 (comment)

[ajorkowski]

I managed to fix my issue as well - I think it may have been the fact that I was using snap to install the dotnet SDK. When I used apt instead this resolved the segmentation fault.

[nikjuice]

Workaround mentioned by @henrikwidlund also works for me.