`Failed to create CoreCLR, HRESULT: 0x8007000E` on linux-musl-x86

[am11]

From @ayakael #77667 (comment)

I'm getting an execution failure when trying to run the resulting SDK. Running dotnet --info with the following SDK in linux-musl-x86 chroot yields a freeze, and then eventually a Failed to create CoreCLR, HRESULT: 0x8007000E. It seems like CoreCLR tries to allocate all of the available memory for some reason. @am11 I see that you got the build-rootfs.sh script working for linux-musl-x86, have you managed a successful crossbuild to linux-musl-x86?

I tried stracing it, but could only attach the process after execution.
strace.txt

Edit: The following patchset is used to build the SDK: https://lab.ilot.io/ayakael/dotnet-stage0

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[am11]

@ayakael, I have only tried building runtime, didn't test the binaries.

Running dotnet --info with the following SDK

I don't have permission to download it. :)

Failed to create CoreCLR, HRESULT: 0x8007000E

BTW, were you testing under VM / baremetal install or QEMU? CoreCLR-PAL has some issues with QEMU (even on 64-bit archs).

[am11]

From @ayakael #77667 (comment)

Woops, here is a functional link: dotnet-sdk-8.0.100-preview.2.23157.25-r1-linux-musl-x86.tar.xz

I tested first within a chroot of alpine-x86 that was in LXC, and then within a chroot in a qemu based env. Both behave the same.

[am11]

Thanks @ayakael. I created a HyperV VM on Windows x64 and installed alpine 32 bit to rule out the emulation factor:

dotnet --info with your SDK build is failing in this VM as well.

@janvorli, this seems like a memory mapping issue on 32-bit Alpine, where DOTNET_EnableWriteXorExecute=0 and/or DOTNET_GCHeapHardLimit=... do not help.

strace -f dotnet --info -> http://sprunge.us/S9saN5

$ cat /proc/meminfo
MemTotal:         308524 kB
MemFree:          218152 kB
MemAvailable:     108400 kB
Buffers:            1020 kB
Cached:            29348 kB
SwapCached:          180 kB
Active:             5804 kB
Inactive:          21904 kB
Active(anon):         68 kB
Inactive(anon):      344 kB
Active(file):       5736 kB
Inactive(file):    21560 kB
Unevictable:        3072 kB
Mlocked:               0 kB
HighTotal:        151072 kB
HighFree:          94044 kB
LowTotal:         157452 kB
LowFree:          124108 kB
SwapTotal:       4194300 kB
SwapFree:        4191476 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:           344 kB
Mapped:             2344 kB
Shmem:              3072 kB
KReclaimable:       7992 kB
Slab:              19800 kB
SReclaimable:       7992 kB
SUnreclaim:        11808 kB
KernelStack:         640 kB
PageTables:          284 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     4348560 kB
Committed_AS:       7956 kB
VmallocTotal:     122880 kB
VmallocUsed:       26060 kB
VmallocChunk:          0 kB
Percpu:              328 kB
DirectMap4k:       20472 kB
DirectMap4M:      868352 kB

$ ulimit -a
core file size (blocks)         (-c) 0
data seg size (kb)              (-d) unlimited
scheduling priority             (-e) 0
file size (blocks)              (-f) unlimited
pending signals                 (-i) 31256
max locked memory (kb)          (-l) 64
max memory size (kb)            (-m) unlimited
open files                      (-n) 1024
POSIX message queues (bytes)    (-q) 819200
real-time priority              (-r) 0
stack size (kb)                 (-s) 8192
cpu time (seconds)              (-t) unlimited
max user processes              (-u) 31256
virtual memory (kb)             (-v) unlimited
file locks                      (-x) unlimited

[ayakael]

Thanks @ayakael. I created a HyperV VM on Windows x64 and installed alpine 32 bit to rule out the emulation factor:

dotnet --info with your SDK build is failing in this VM as well.

@janvorli, this seems like a memory mapping issue on 32-bit Alpine, where DOTNET_EnableWriteXorExecute=0 and/or DOTNET_GCHeapHardLimit=... do not help.

strace -f dotnet --info -> http://sprunge.us/S9saN5

$ cat /proc/meminfo
MemTotal:         308524 kB
MemFree:          218152 kB
MemAvailable:     108400 kB
Buffers:            1020 kB
Cached:            29348 kB
SwapCached:          180 kB
Active:             5804 kB
Inactive:          21904 kB
Active(anon):         68 kB
Inactive(anon):      344 kB
Active(file):       5736 kB
Inactive(file):    21560 kB
Unevictable:        3072 kB
Mlocked:               0 kB
HighTotal:        151072 kB
HighFree:          94044 kB
LowTotal:         157452 kB
LowFree:          124108 kB
SwapTotal:       4194300 kB
SwapFree:        4191476 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:           344 kB
Mapped:             2344 kB
Shmem:              3072 kB
KReclaimable:       7992 kB
Slab:              19800 kB
SReclaimable:       7992 kB
SUnreclaim:        11808 kB
KernelStack:         640 kB
PageTables:          284 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     4348560 kB
Committed_AS:       7956 kB
VmallocTotal:     122880 kB
VmallocUsed:       26060 kB
VmallocChunk:          0 kB
Percpu:              328 kB
DirectMap4k:       20472 kB
DirectMap4M:      868352 kB

$ ulimit -a
core file size (blocks)         (-c) 0
data seg size (kb)              (-d) unlimited
scheduling priority             (-e) 0
file size (blocks)              (-f) unlimited
pending signals                 (-i) 31256
max locked memory (kb)          (-l) 64
max memory size (kb)            (-m) unlimited
open files                      (-n) 1024
POSIX message queues (bytes)    (-q) 819200
real-time priority              (-r) 0
stack size (kb)                 (-s) 8192
cpu time (seconds)              (-t) unlimited
max user processes              (-u) 31256
virtual memory (kb)             (-v) unlimited
file locks                      (-x) unlimited

Awesome, thank you for creating the issue. Note that this is the product of a crossbuild from Alpine x86_64 to Alpine x86 via a rootfs dir. I use this method to build the s390x and ppc64le bootstraps, so it is a tested methdology. But as usually crossbuilding to x86 is done via -m32 (which for some reason didn't work when attempted), maybe some bits are being built in 64-bit mode?

[ayakael]

Turns out setting -m32 works, but makes no difference. Maybe relevant, without setting add_linker_flag(-Wl,-z,notext), I get the following error:

 ld.lld: error: relocation R_386_PC32 cannot be used against symbol 'CONTEXT_CaptureContext'; recompile with -fPIC
                     >>> defined in ../../../pal/src/libcoreclrpal.a(context2.S.o)
                     >>> referenced by context2.S:92 (/var/build/dotnet-stage0/src/dotnet-v8.0.100-preview.2/src/runtime/src/coreclr/pal/src/arch/i386/context2.S:92)
                     >>>               context2.S.o:(RtlCaptureContext) in archive ../../../pal/src/libcoreclrpal.a
                     clang-15: error: linker command failed with exit code 1 (use -v to see invocation)
                     make[2]: *** [tools/superpmi/superpmi-shim-simple/CMakeFiles/superpmi-shim-simple.dir/build.make:425: tools/superpmi/superpmi-shim-simple/libsuperpmi-shim-simple.so] Error 1
                     make[1]: *** [CMakeFiles/Makefile2:4511: tools/superpmi/superpmi-shim-simple/CMakeFiles/superpmi-shim-simple.dir/all] Error 2
                     make[1]: *** Waiting for unfinished jobs....

[am11]

Turns out setting -m32 works

Nice, can we remove conditions around -m32 from #83464 since it doesn't break the build?

Another difference is linkage of libucontext library on linux-musl-x86 for libunwind, which we don't need on linux-musl-x64. But that too seem unrelated to memory map issue.

I think the issue is that PAL doesn't handle some case and we run into infinite recursion (the strace posted above is way too many > 10 MB of mremap / munmap lines which suggests lack of error handling somewhere in PAL). It could be that we can make PAL resilient against this system state as a general improvement. Similar issues are reported previously: #79612, #13027 etc. but their resolution is mostly about lifting virtual memory limit. In this case, we have that unlimited so it could be a bug in 32-bit specific branch code somewhere. I haven't investigated with debug build.

[ayakael]

Turns out setting -m32 works

Nice, can we remove conditions around -m32 from #83464 since it doesn't break the build?

Another difference is linkage of libucontext library on linux-musl-x86 for libunwind, which we don't need on linux-musl-x64. But that too seem unrelated to memory map issue.

I think the issue is that PAL doesn't handle some case and we run into infinite recursion (the strace posted above is way too many > 10 MB of mremap / munmap lines which suggests lack of error handling somewhere in PAL). It could be that we can make PAL resilient against this system state as a general improvement. Similar issues are reported previously: #79612, #13027 etc. but their resolution is mostly about lifting virtual memory limit. In this case, we have that unlimited so it could be a bug in 32-bit specific branch code somewhere. I haven't investigated with debug build.

Yeah, we could. The following patch after toolchain changes works:

diff --git a/src/runtime/eng/common/cross/toolchain.cmake b/src/runtime/eng/common/cross/toolchain.cmake
index 2bb1e0845..fed3b0fad 100644
--- a/src/runtime/eng/common/cross/toolchain.cmake
+++ b/src/runtime/eng/common/cross/toolchain.cmake
@@ -284,8 +284,7 @@ elseif(TARGET_ARCH_NAME STREQUAL "x86")
     add_toolchain_linker_flag("--target=${TOOLCHAIN}")
     add_toolchain_linker_flag("-Wl,--rpath-link=${CROSS_ROOTFS}/usr/lib/gcc/${TOOLCHAIN}")
-  else()
-    add_toolchain_linker_flag(-m32)
   endif()
+  add_toolchain_linker_flag(-m32)
   if(TIZEN)
     add_toolchain_linker_flag("-B${CROSS_ROOTFS}/usr/lib/gcc/${TIZEN_TOOLCHAIN}")
     add_toolchain_linker_flag("-L${CROSS_ROOTFS}/lib")
@@ -324,9 +323,8 @@ if(TARGET_ARCH_NAME MATCHES "^(arm|armel)$")
 elseif(TARGET_ARCH_NAME STREQUAL "x86")
   if(EXISTS ${CROSS_ROOTFS}/usr/lib/gcc/i586-alpine-linux-musl)
     add_compile_options(--target=${TOOLCHAIN})
-  else()
-    add_compile_options(-m32)
   endif()
+  add_compile_options(-m32)
   add_compile_options(-Wno-error=unused-command-line-argument)
 endif()

edit Updated both PRs with above change

[ayakael]

Circling back on this, I now get the following error on 8.0.0-preview.7:

$ ./dotnet --info
 Fatal error. SSE is not supported on the processor.
 Aborted