Mold failure to install and segfault when run

[RivenSkaye]

Description / Steps to reproduce the issue

When installing the mold linker (at least for mingw-w64-x86_64 and mingw-w64-clang64 MSYS2 environments) the install terminates with the following warning:

:: Proceed with installation? [Y/n]
(2/2) checking keys in keyring                                        [#####################################] 100%
(2/2) checking package integrity                                      [#####################################] 100%
(2/2) loading package files                                           [#####################################] 100%
(2/2) checking for file conflicts                                     [#####################################] 100%
(2/2) checking available disk space                                   [#####################################] 100%
:: Processing package changes...
(1/2) installing mingw-w64-x86_64-mimalloc                            [#####################################] 100%
(2/2) installing mingw-w64-x86_64-mold                                [#####################################] 100%
warning: warning given when extracting /mingw64/bin/ld.mold.exe (Can't create '/mingw64/bin/ld.mold.exe')

Subsequently attempting to run any mold command (e.g. mold --version) results in data being written to stdout as expected, followed by a segfault

> mold --version
mold 1.10.1 (compatible with GNU ld)
Segmentation fault

Consistent MRE for both (works with anything passed to mold, even no args or --help):

> pacman -S mingw-w64-x86_64-mold --noconfirm && mold --version

I know for sure that using the clang64 version fails with the same error, I'm not sure about the other environments, but I expect them to be no different.

Expected behavior

mold installing without warnings, /$MINGW_PREFIX/bin/ld.mold.exe existing, no segfaults when calling mold

Actual behavior

No warnings on installing, /$MINGW_PREFIX/bin/ld.mold.exe does not exist, mold segfaults when called

Verification

• [X] I have verified that my MSYS2 is up-to-date before submitting the report (see https://www.msys2.org/docs/updating/)

Windows Version

MINGW64_NT-10.0-19045

MINGW environments affected

• [X] MINGW64
• [ ] MINGW32
• [ ] UCRT64
• [X] CLANG64
• [ ] CLANG32
• [ ] CLANGARM64

Are you willing to submit a PR?

Yes, however #2631 is in-progress by @Biswa96

[RivenSkaye]

"the other environments" being clang-aarch64 and ucrt-x86_64, as mold is not available in the clang-32 and mingw-w32 environments

[Biswa96]

No new 32 bit packages are being added because most users use 64 bit Windows OS.

[Biswa96]

The crash happens within mimalloc.

Click here to see the backtrace

(gdb) r
Starting program: F:\msys64\ucrt64\bin\mold.exe --version
[New Thread 2220.0x1130]
[New Thread 2220.0x11b8]
mimalloc-redirect: error: unable to find target module.
mimalloc-redirect: warning: standard malloc is _not_ redirected! -- using regular malloc/free
mold 1.10.1 (compatible with GNU ld)
mimalloc: warning: mi_free_size: pointer might not point to a valid heap region: 000002028D76BFD0
(this may still be a valid very large allocation (over 64MiB))

Thread 1 received signal SIGSEGV, Segmentation fault.
0x00007ffa4f967ecf in mi_checked_ptr_segment (p=0x2028d76bfd0, msg=0x7ffa4f979915 <__func__.0+2325> "mi_free_size") at mimalloc-2.0.9/src/alloc.c:516
516           if mi_likely(_mi_ptr_cookie(segment) == segment->cookie) {
(gdb) bt
#0  0x00007ffa4f967ecf in mi_checked_ptr_segment (p=0x2028d76bfd0, msg=0x7ffa4f979915 <__func__.0+2325> "mi_free_size") at mimalloc-2.0.9/src/alloc.c:516
#1  0x00007ffa4f9682d5 in _mi_usable_size (p=0x2028d76bfd0, msg=0x7ffa4f979915 <__func__.0+2325> "mi_free_size") at mimalloc-2.0.9/src/alloc.c:605
#2  0x00007ffa4f968389 in mi_free_size (p=0x2028d76bfd0, size=513) at mimalloc-2.0.9/src/alloc.c:628
#3  0x00007ff69323ab2b in ?? ()
#4  0x000002028d76bfd0 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) q

Upstream mimalloc is full of this type of memory corruption issues.

[RivenSkaye]

most users use 64 bit Windows OS.

I'm aware, I just figured I'd specify them for completeness' sake, especially considering the 32-bit envs are still listed in the template. Would you want me to move the mimalloc crash to a separate issue? If so, feel free to close this one as completed, since a working PKGBUILD is available now

[Biswa96]

Would you want me to move the mimalloc crash to a separate issue?

No, no, its ok. We can continue here. As of writing this, only mold is using mimalloc. So, one can reproduce the issue in this way.

[RivenSkaye]

A couple months have passed, $MINGW_PREFIX/bin/ld.mold.exe now gets created successfully, but the segfault still happens. Promised Windows support has seemingly been dropped as well, favoring sold (commercially licensed, paid version of the linker) to implement it come v3.0; I'm in favor of closing this issue and would like to propose removing mold from the packages. Any opinions on the matter?

Alternatively I could change the title on this issue to something relating to mimalloc segfaults, but that'd still leave the proposition of removing the mold package, as it doesn't seem like it'll ever serve a real purpose.

Refs: rui314/mold#190, bluewhalesystems/sold#1 and bluewhalesystems/sold#8

[Biswa96]

I am not sure if mold package can be removed. I have seen that mold does not support Windows platform. @3rav may have some opinion.

[3rav]

It can be removed, but I'm wondering about switching to the MIT license, I think the open version will have a Windows version

[RivenSkaye]

Mold is the MIT licensed version, and the issues I linked all explicitly state that it will not have PE support. That means it won't support Windows and a few other lesser known OSes. That functionality will be for the paid linker version (Sold) only.

[3rav]

Mold is the MIT licensed version, and the issues I linked all explicitly state that it will not have PE support. That means it won't support Windows and a few other lesser known OSes. That functionality will be for the paid linker version (Sold) only.

https://github.com/bluewhalesystems/sold/issues/43#issuecomment-1849204233

[3rav]

Sold moved to MIT license: https://github.com/bluewhalesystems/sold/commit/41b49175f58c73dbc0fc769128581de6b981863d

The question is what (if at all) will be developed?

[RivenSkaye]

Looks like the answer to that is nothing at all. Based on the possibility that MS might be making a faster MSVC linker they're just not supporting the platform altogether. I'll respond to that thread to check what the plans are for cross-compilation support to see if we could maybe bootstrap an initial working version for that and then invoking cross-compilation by default when using the linker.

MSVC is still much slower for now, and anyone working with other toolchains to support windows is currently just SoL unless a different parallelized linker shows up.