Alpine 3.13 image is crashing on dotnet test #24189
Comments
|
I've confirmed it's a segfault crash. It occurs when calling I've created a simple repro project that doesn't involve using (var context = new ItemsContext(options))
{
context.Database.EnsureCreated();
}The call to Repro steps
I've also collected a crash dump: |
|
Moving to efcore repo for further investigation. |
|
Yes, it is supposed to work on Alpine linux. It seems like it breaks 1-2 times per year, usually due to something in the environment changing, IIRC. |
|
@ericsink Is there anything we can do help understand the issue on Alpine? I don't think there is anything we can change on our end, unless I'm missing something. |
|
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. |
|
Thanks @ericsink |
|
I tried the repro.zip above and it didn't fail. On the possibility that I did something wrong, one of my coworkers tried it, and no crash for them either. Still quite possible we're doing the repro incorrectly somehow. Can someone point me to a list of things that changed in the docker image between 3.12 and 3.13 ? |
Did it successfully output |
|
Ah, I see. No, it did not output |
|
Not sure, but perhaps something in #14504 would be helpful here. |
Sure thing, I went this path also, and found this comparison: |
|
Oh. I didn't realize the 3.12 and 3.13 referred to versions numbers of Alpine Linux itself. @ChaosEngine FWIW, the links you gave appear to refer to Alpine's sqlite package, which is probably not involved here, but I cannot say for certain. The most likely case here is that my |
|
More info, in case it helps anyone recognize a problem: My My current version of ubuntu for this build is 16.04 xenial. My current version of the A current question is whether this build configuration results in things that are compatible with alpine 3.12 but not with alpine 3.13. |
Alpine 3.13 was upgraded to musl 1.2 and also had some changes around time64. I wonder if either of those two things are related. See the Alpine 3.13 release notes. |
|
FWIW, my alpine3.13 |
|
Also I've observed following when playing with vanilla libsqlite: Looks like when installed original libsqlite3 (musl compiled and alpine-3.13 build) and overwriting dotnet build linux-x64 native version of sqlite - the problem is gone, otherwise it is very reproducible. |
|
I'm going to try and get setup to build an e_sqlite3 actually under alpine 3.13. |
|
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. :-) |
|
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, looks like a homework for me :-) Will try to give this a shot during weekend (lockdown on my side so what else). |
|
Many thanks to everyone helping out on this. Much appreciated. :-) |
|
Another thought I had: Let's assume we find that e_sqlite3 for alpine 3.13 needs to be built on 3.13. I speculate that the resulting build will therefore not work on alpine before 3.13. So are we going to need to maintain two builds? |
|
While doing the compilation I noticed something interesting. also my original repro from the docs works with test project when run with Is it possible that default dotnet runtime on alpine3.13 is not detected properly somehow? |
|
It seems to be the same as reported here: dotnet/runtime#28303 (comment)
I think this proves it. I run built app ( loading |
|
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: Adding @wfurt who added this rid to see if he has an idea here. @wfurt , take a look at the output shown here: #24189 (comment). Why would |
|
It is missing in Microsoft.NETCore.App/5.0.4/Microsoft.NETCore.App.deps.json Adding it there gives expected RID |
|
cc: @Anipik @aik-jahoda . The sources looks ok to me. |
|
@ajcvickers @wfurt Is there any plan (before 6.0) to add the alpine.3.13 RID into Microsoft.NETCore.App.deps.json? I tested the 5.0.7 SDK docker image and the RID is still incorrect. Could it be fixed in the next minor version of 5.0.7? So we won't get the "Test host process crashed" error in the container while running unit tests, our code is being upgraded from .NET Core 3.1 to .NET 5.0 and we would like to maintain the OS version unchanged in the docker image. Thanks. |
|
Any idea @ericstj ? It seems like the RID does not propagate consistently. |
|
(See also dotnet/runtime#50739) |
|
@Anipik's change dotnet/runtime@95fe690 did this. My best guess is that the runtime consolidation in 5.0 missed picking up the live built runtime.json and is using some restored copy (or SDK copy). cc @jkoritzinsky @ViktorHofer |
|
Thanks @ericstj. So if we make rid update to add 3.14 it would be missed as well? |
|
I didn't check that, but you could by examining the tar.gz file. 3.x was done in a different way (due to separate repos) and underwent a lot more additions that I expect would have noticed this, so I suspect the bug is not there. Can't know for sure until someone root-causes the deps file generation on 5.0. cc @dagood |
|
I think I misread your statement as .NETCore 3.x, but you meant an addition to of 3.14 to 5.0. There's probably a way to make it work correctly. I would ask @dagood or @jkoritzinsky as they know the most about this part of the shared framework creation process. It looks to me like the 5.0 tools relied on getting the runtime graph from some package that was restored as part of the project: https://github.com/dotnet/arcade/blob/7e1e1ff990487b0c74e0fb17b4169bc5378fe778/src/Microsoft.DotNet.Build.Tasks.SharedFramework.Sdk/src/ProcessSharedFrameworkDeps.cs#L56-L57 |
|
Here's another 5.0 RID change: dotnet/runtime#48203 I wonder if that has the same problem? |
|
It looks like the The |
|
Let's move this discussion to dotnet/runtime#50739. Let's make that a servicing issue and address it in the next release. |
|
faced the same issue today. |
Describe the Bug
Running
dotnet teston Alpine 3.13 docker based image crashes test runner.When running on mcr.microsoft.com/dotnet/sdk:5.0-alpine3.12 it succeeds
When running on mcr.microsoft.com/dotnet/sdk:5.0-alpine it fails
Steps to Reproduce
Dockerized repro based on https://github.com/dotnet/EntityFramework.Docs (https://github.com/dotnet/EntityFramework.Docs/tree/master/samples/core/Miscellaneous/Testing/ItemsWebApi/Tests specifically)
Start docker sdk alpine image
docker run -it --rm mcr.microsoft.com/dotnet/sdk:5.0-alpineand then. execute this in interactive terminal..
Other Information
The same stuff when run with
docker run -it --rm mcr.microsoft.com/dotnet/sdk:5.0-alpineworks and just properly fails saying LocalDB is not avaialblre under Linux :-)Output of
docker versionOutput of
docker infoThe text was updated successfully, but these errors were encountered: