efcore: Alpine 3.13 image is crashing on dotnet test

I’ve confirmed it’s a segfault crash. It occurs when calling context.Database.EnsureCreated() when using a file-based connection for SQLite. So it seems to be related to Entity Framework or native implementation of SQLite. I saw that the db file does get created on the file system.

I’ve created a simple repro project that doesn’t involve dotnet test. The crux of the repro is here:

using (var context = new ItemsContext(options))
{
  context.Database.EnsureCreated();
}

The call to EnsureCreated is what causes the crash.

Repro steps

1. Unzip repro.zip to new folder
2. docker build -t app .
3. docker run --rm -it app

I’ve also collected a crash dump: core.zip

Let’s move this discussion to https://github.com/dotnet/runtime/issues/50739. Let’s make that a servicing issue and address it in the next release.

Based on what I saw above, it looks like everything succeeded with Alpine docker image 3.12 and then failed with 3.13. So I had been assuming something changed in between that caused the break.

One possibility I have not investigated yet is that maybe “the thing that changed” would require me to build the alpine sqlite library differently, such as, for example, with a more recent compiler or C lib, etc.

I’ll try the repro above and see if it yields any clues.

Great investigative work, @ChaosEngine. Definitely looks related to the rid.

It’s strange because I’ve confirmed that alpine.3.13 is defined as an available rid:

$ docker run -it --rm mcr.microsoft.com/dotnet/sdk:5.0-alpine
/ # cat ./usr/share/dotnet/sdk/5.0.201/RuntimeIdentifierGraph.json | grep alpine.3.13
    "alpine.3.13": {
    "alpine.3.13-arm": {
        "alpine.3.13",
    "alpine.3.13-arm64": {
        "alpine.3.13",
    "alpine.3.13-x64": {
        "alpine.3.13",

Adding @wfurt who added this rid to see if he has an idea here. @wfurt , take a look at the output shown here: https://github.com/dotnet/efcore/issues/24189#issuecomment-798542743. Why would dotnet --info print out linux-musl-x64 for the rid on Alpine 3.13 while it prints out alpine.3.12-x64 on Alpine 3.12?

It seems to be the same as reported here: https://github.com/dotnet/runtime/issues/28303#issuecomment-646994218

 $ docker run -it --rm -v $(pwd):/app --workdir /app mcr.microsoft.com/dotnet/sdk:5.0-alpine
/app # dotnet --info
.NET SDK (reflecting any global.json):
 Version:   5.0.201
 Commit:    a09bd5c86c

Runtime Environment:
 OS Name:     alpine
 OS Version:  3.13
 OS Platform: Linux
 RID:         linux-musl-x64
 Base Path:   /usr/share/dotnet/sdk/5.0.201/

RID: linux-musl-x64

$ docker run -it --rm -v $(pwd):/app --workdir /app mcr.microsoft.com/dotnet/sdk:5.0-alpine3.12
/app # dotnet --info
.NET SDK (reflecting any global.json):
 Version:   5.0.201
 Commit:    a09bd5c86c

Runtime Environment:
 OS Name:     alpine
 OS Version:  3.12
 OS Platform: Linux
 RID:         alpine.3.12-x64
 Base Path:   /usr/share/dotnet/sdk/5.0.201/

RID: alpine.3.12-x64 and this could be the imain issue here, app assembly not linking to proper native SQLite runtime???

I think this proves it. I run built app (/app/bin/Debug/net5.0/app) in gdb and force a crash, than showed loaded shared libraries.

/app # gdb /app/bin/Debug/net5.0/app

Type "apropos word" to search for commands related to "word"...
Reading symbols from /app/bin/Debug/net5.0/app...
(No debugging symbols found in /app/bin/Debug/net5.0/app)
(gdb) r
Starting program: /app/bin/Debug/net5.0/app
warning: Error disabling address space randomization: Operation not permitted
[New LWP 192]
[New LWP 193]
[New LWP 194]
[New LWP 195]
[New LWP 196]
[New LWP 197]
[New LWP 198]
[New LWP 199]
[New LWP 200]
[New LWP 201]

Thread 1 "app" received signal SIGSEGV, Segmentation fault.
0x000000000000e5c6 in ?? ()
(gdb) info sharedlibrary
From                To                  Syms Read   Shared Object Library
0x00007f46227c4070  0x00007f462280b6e3  Yes (*)     /lib/ld-musl-x86_64.so.1
0x00007f46226cc820  0x00007f4622755cf1  Yes (*)     /usr/lib/libstdc++.so.6
0x00007f46225f62f0  0x00007f46226065b1  Yes (*)     /usr/lib/libgcc_s.so.1
0x00007f4622591840  0x00007f46225cc2b7  Yes (*)     /usr/share/dotnet/host/fxr/5.0.4/libhostfxr.so
0x00007f4622545900  0x00007f46225781a1  Yes (*)     /usr/share/dotnet/shared/Microsoft.NETCore.App/5.0.4/libhostpolicy.so
0x00007f4621dd1290  0x00007f462228daa4  Yes (*)     /usr/share/dotnet/shared/Microsoft.NETCore.App/5.0.4/libcoreclr.so
0x00007f458710aff0  0x00007f45872d3d34  Yes (*)     /usr/share/dotnet/shared/Microsoft.NETCore.App/5.0.4/libclrjit.so
0x00007f4586ac09c0  0x00007f4586ac899a  Yes (*)     /usr/share/dotnet/shared/Microsoft.NETCore.App/5.0.4/libSystem.Native.so
0x00007f458696f480  0x00007f4586a17341  Yes (*)     /usr/lib/libicuuc.so.67
                                        Yes (*)     /usr/lib/libicudata.so.67
0x00007f4584c57560  0x00007f4584d63031  Yes (*)     /usr/lib/libicui18n.so.67
0x00007f45842c0d50  0x00007f458437b0f0  Yes (*)     /app/bin/Debug/net5.0/runtimes/linux-x64/native/libe_sqlite3.so
(*): Shared library is missing debugging information.

loading /app/bin/Debug/net5.0/runtimes/linux-x64/native/libe_sqlite3.so

While doing the compilation I noticed something interesting. When added runtime suffix for alpine (-r alpine-x64 )the repro.zip case worked:

/app # dotnet build -r alpine-x64
Microsoft (R) Build Engine version 16.9.0+57a23d249 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
  All projects are up-to-date for restore.
  app -> /app/bin/Debug/net5.0/alpine-x64/app.dll

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:04.07
/app # rm -rf bi^C
/app # rm -rf bin/ obj/ Test.db
/app # dotnet build -r alpine-x64
Microsoft (R) Build Engine version 16.9.0+57a23d249 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
  Restored /app/app.csproj (in 874 ms).
  app -> /app/bin/Debug/net5.0/alpine-x64/app.dll

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:10.50

/app # bin/Debug/net5.0/alpine-x64/app
created

also my original repro from the docs works with test project when run with dotnet test -v m --runtime alpine-x64

Is it possible that default dotnet runtime on alpine3.13 is not detected properly somehow? Digging deeper into this…🧐

Ok, looks like a homework for me 😃 Will try to give this a shot during weekend (lockdown on my side so what else).

You could try these instructions to upgrade your WSL Alpine installation to 3.13. And here are instructions for for installing gcc on Alpine.

OK, I haven’t gotten anywhere on this.

I have no experience with alpine linux, and very little experience with docker. I want to learn these things, but having my education in the critical path of this issue may not be a good idea.

I assume that if I just build sqlite on alpine 3.13 the resulting library would work.

Anybody want to give me just enough docker knowledge to run gcc under alpine 3.13 ?

I have wsl 2 installed, which I use regularly, but I don’t see a wsl image for alpine 3.13 yet.

Feel free to just tell me to go back and do my homework, but if you want to move this bug along, telling me exactly what commands to type would probably do that. 😃

I’m going to try and get setup to build an e_sqlite3 actually under alpine 3.13.