build.sh causes segfault on Alpine Linux just after running Darc #1868
Comments
|
If you're familiar with how to run it in a debugger, get a memory dump, that kind of thing, that would be good to be able to report the bug to dotnet/arcade (where Darc is maintained) or dotnet/runtime (if it's an underlying Runtime bug with We don't have CI running for We have run into a segfault due to not having enough memory, although elsewhere in the build: #1687. It might be useful if you could give some machine info. |
|
Not sure how to get a memory dump, but normally I'm able to get a backtrace with gdb and all that. dotnet seems to react a bit different to the usual Linux programs however... (this was the failing command) I doubt it's a lack of memory, this system has 32GB's of it 😉 Also running on a R7 1700. |
|
I think there's a mistake here: The |
|
That... Is not what I expected and totally true. The backtrace doesn't seem that useful to me but hopefully you disagree. |
|
It looks like this libgit is being used: And based on the name here ( There should be a alpine-x64/native/libgit2-7ce88e6.so; I wonder why that's not getting used. As a hack, what happens if you delete everything under |
|
|
Doh, I asked for |
|
I would expect ...
"LibGit2Sharp.NativeBinaries/2.0.289": {
"runtimeTargets": {
"runtimes/alpine-x64/native/libgit2-7ce88e6.so": {
"rid": "alpine-x64",
"assetType": "native",
"fileVersion": "0.0.0.0"
},
...
"runtimes/debian.9-x64/native/libgit2-7ce88e6.so": {
"rid": "debian.9-x64",
"assetType": "native",
"fileVersion": "0.0.0.0"
},
...I noticed that your I see in my |
|
Keeping the I'm guessing the scripts will work on any stable version but not on edge then, which has a moving version number (current latest stable + 1 basically). |
|
It's not the scripts so much as the .NET SDK itself in this case--but yeah, problems come up with "unknown" RIDs like this. New versions of distros tend to be added to the RID graph as they come alive and get .NET support, although sometimes new distro versions are added ahead of time too. I vaguely remember an issue in dotnet/runtime proposing that the RID graph shouldn't be as static (and should allow for higher than expected versions) but can't find it. On the dotnet/source-build side, we do want to go further to support arbitrary RIDs, tracked by #297. This would help with newer-than-expected RIDs and also for distros that will never be "official" in dotnet/runtime's |
|
Is there an available workaround for now that doesn't involve letting Also, A version of libunwind (1.4.) however is available in the Alpine repositories, is it possible to make it use that? |
I dont know of one. We fixed something like this before via libgit2/libgit2sharp#1714 but maybe it doesn't handle alpine too well?
I think the build output is confusing. It's probably not related to libunwind. It reminds me of dotnet/coreclr#28045, but that was only needed for 2.1. I wonder why/how you are getting this. What version of clang is this?
Yes. I doubt it will fix your problem, but you can pass |
|
You're right, libunwind from the system doesn't help, but it being possible does help the chances of this package eventually being accepted to Alpine. Is there somewhere I can read up on these build arguments? I'm using Clang 10.0.1. |
You could add a patch to the Alpine build that inserts the source-build/eng/common/darc-init.sh Lines 74 to 80 in b4d00c3 (We call that from https://github.com/dotnet/source-build/blob/release/3.1/tools-local/acquire-darc/acquire-darc.proj#L5. A patch there would also be reasonable, but not sure if you're familiar with MSBuild code. The
This might be beyond a reasonable fix in libgit2sharp--it seems to me they would have to implement their own RID tree to be able to do better than they do now, which seems possible, but it's not something I'd be eager to maintain in their shoes when .NET should do this for me. 😄 It seems to me the "try a few
I think it would make sense to describe how using system libraries works at https://github.com/dotnet/source-build/blob/release/3.1/Documentation/packaging-installation.md at some point since it's particularly important when building for a distro. |
|
The fix that I imagine we'd do at some point in the future in source-build would be either:
|
That does the trick yes, thanks.
I'm not sorry, this is my first time looking into this whole ordeal.
Yes please, also, including instructions on how to do a complete offline build would be nice. |
|
I guess I didn't quite link to the right doc for that. There are actually instructions for how to do an offline build here (and notes for how to use system libraries would go somewhere around there I guess): https://github.com/dotnet/source-build/tree/release/3.1/Documentation#building-net-core-sdk-and-a-source-tarball |
|
I'm splitting off the coreclr build failure and request to document flags for using system libraries rather than internal ones. |
|
I think everything here is tracked elsewhere now:
Let me know if there's something I missed! Thanks for filing those separate followup issues. |
I'm trying to compile dotnet from source but somewhere in the
build.shprocess just after running Darc the dotnet executable segfaults. Note that even though it says it could not find zlib,zlib-devis installed.The text was updated successfully, but these errors were encountered: