alr install gnatformat on Windows creates a non-executing binary

[johnperry-math]

Checklist

• I've searched for similar issues and found none.
• I've included the output of alr version.
• I've included complete steps to reproduce my issue.

Describe the bug
A fresh install of alire and then gnatformat on a Windows 10 system produces an executable, but the executable fails to do anything when run:

• When I run the binary from the command line, it returns silently. It does not format files.
• When run from File Explorer, it reports missing dll's; when the dll's are copied to a path, it runs longer, but still returns silently, without any errors.
• When run from Msys, it segfaults.

I've tried building with gnat-native 15.2.1 and 14.2.1.

To Reproduce
Steps to reproduce the behavior:

1. Fresh alire install on a previously Ada-free computer.
2. Run alr install gnatformat.
3. Add ~\.alire\bin to path (if it isn't already).
4. Create a new binary crate. Edit a file with bad formatting.
5. Run gnatformat.exe from the command line. See no output.
6. Inspect source file. Observe no change in formatting.
7. Run gnatformat.exe -P project.gpr from the command line. See no output.
8. Inspect source file. Observe no change in formatting.

Expected Behavior
Repeat steps 1-5 (modulo different output when running a working gnatformat).
6. Inspect source file. Observe changed formatting.
7. Run gnatformat.exe -P project.gpr from the command line. See no output. (?)
8. Inspect source file. Observe changed formatting.

alr version

APPLICATION
alr version:               2.1.0
libalire version:          2.1.0
source commit:             2681b313d08224014fa3f5e4f76e9c75347213d2
source changes:            clean
compilation date:          2025-03-04 10:22:55
compiled with version:     14.2.0

CONFIGURATION
home folder:               C:\Users\john.perry
settings folder:           C:\Users\john.perry\AppData\Local\alire\settings
cache folder:              C:\Users\john.perry\AppData\Local\alire\cache
vault folder:              C:\Users\john.perry\AppData\Local\alire\cache\releases
build folder:              C:\Users\john.perry\AppData\Local\alire\cache\builds
temp folder:               C:\Users\JOHN~1.PER\AppData\Local\Temp
force flag:                FALSE
non-interactive flag:      FALSE
community index branch:    stable-1.4.0
compatible index versions: ^1.1 & <=1.4.0
indexes folder:            C:\Users\john.perry\AppData\Local\alire\settings\indexes
indexes metadata:          OK
index #1:                  (community) git+https://github.com/alire-project/alire-index#stable-1.4.0
toolchain folder:          C:\Users\john.perry\AppData\Local\alire\cache\toolchains
toolchain assistant:       disabled
tool #1 gnat:              gnat_native=15.2.1
tool #2 gprbuild:          gprbuild=25.0.1
system package manager:    C:\Users\john.perry\AppData\Local\alire\cache\msys64\usr\bin\pacman.exe
distro detection disabled: FALSE

WORKSPACE
root status:               VALID
root release:              parameters=0.1.0-dev
root load error:           none
root folder:               D:\Ada\Simulator_In_Ada\parameters
current folder:            D:\Ada\Simulator_In_Ada\parameters

SYSTEM
distribution:              MSYS2
host-arch:                 X86_64
os:                        WINDOWS
target:                    NATIVE
toolchain:                 USER
word-size:                 BITS_64

alr logs
I don't think this is pertinent, but correct me if I'm wrong.

[johnperry-math]

Related discussion, and a workaround, here.

[jcmoyer]

Here is the stacktrace for the program. I get this when compiling with both gnat_native (=15.2.1) and gnat_external (msys package: mingw-w64-x86_64-gcc-ada=15.2.0-8) toolchains. Just to be absolutely sure my msys install isn't interfering with the build, I also tested in a clean alire environment and let it install and manage a separate msys installation. The final binary has the same problem.

#0  0x00007ffefeab1ecf in ntdll!RtlRaiseNoncontinuableException () from C:\WINDOWS\SYSTEM32\ntdll.dll
#1  0x00007ffefeb12636 in ntdll!RtlRaiseStatus () from C:\WINDOWS\SYSTEM32\ntdll.dll
#2  0x00007ffefeac3f96 in ntdll!memset () from C:\WINDOWS\SYSTEM32\ntdll.dll
#3  0x00007ffefea41040 in ntdll!RtlVirtualUnwind () from C:\WINDOWS\SYSTEM32\ntdll.dll
#4  0x00007ffefea40e7b in ntdll!RtlVirtualUnwind () from C:\WINDOWS\SYSTEM32\ntdll.dll
#5  0x00007ffefea624a8 in ntdll!RtlRaiseException () from C:\WINDOWS\SYSTEM32\ntdll.dll
#6  0x00007ffefeab147e in ntdll!KiUserExceptionDispatcher () from C:\WINDOWS\SYSTEM32\ntdll.dll
#7  0x00007ffefeab1ecf in ntdll!RtlRaiseNoncontinuableException () from C:\WINDOWS\SYSTEM32\ntdll.dll
#8  0x00007ffefeb12636 in ntdll!RtlRaiseStatus () from C:\WINDOWS\SYSTEM32\ntdll.dll
#9  0x00007ffefeac3f96 in ntdll!memset () from C:\WINDOWS\SYSTEM32\ntdll.dll
#10 0x00007ffefea41040 in ntdll!RtlVirtualUnwind () from C:\WINDOWS\SYSTEM32\ntdll.dll
#11 0x00007ffefea40e7b in ntdll!RtlVirtualUnwind () from C:\WINDOWS\SYSTEM32\ntdll.dll
...... repeated loop of memset, RtlRaiseStatus, etc .......
#10604 0x00007ffefeab147e in ntdll!KiUserExceptionDispatcher () from C:\WINDOWS\SYSTEM32\ntdll.dll
#10605 0x00007ffefeab1ecf in ntdll!RtlRaiseNoncontinuableException () from C:\WINDOWS\SYSTEM32\ntdll.dll
#10606 0x00007ffefeb12636 in ntdll!RtlRaiseStatus () from C:\WINDOWS\SYSTEM32\ntdll.dll
#10607 0x00007ffefeac3f96 in ntdll!memset () from C:\WINDOWS\SYSTEM32\ntdll.dll
#10608 0x00007ffefea41040 in ntdll!RtlVirtualUnwind () from C:\WINDOWS\SYSTEM32\ntdll.dll
#10609 0x00007ffefea40e7b in ntdll!RtlVirtualUnwind () from C:\WINDOWS\SYSTEM32\ntdll.dll
#10610 0x00007ffefea624a8 in ntdll!RtlRaiseException () from C:\WINDOWS\SYSTEM32\ntdll.dll
#10611 0x00007ffefeab147e in ntdll!KiUserExceptionDispatcher () from C:\WINDOWS\SYSTEM32\ntdll.dll
#10612 0x00007ffefeab1ecf in ntdll!RtlRaiseNoncontinuableException () from C:\WINDOWS\SYSTEM32\ntdll.dll
#10613 0x00007ffefeb12636 in ntdll!RtlRaiseStatus () from C:\WINDOWS\SYSTEM32\ntdll.dll
#10614 0x00007ffefeac3f96 in ntdll!memset () from C:\WINDOWS\SYSTEM32\ntdll.dll
#10615 0x00007ffefea41040 in ntdll!RtlVirtualUnwind () from C:\WINDOWS\SYSTEM32\ntdll.dll
#10616 0x00007ffefea40e7b in ntdll!RtlVirtualUnwind () from C:\WINDOWS\SYSTEM32\ntdll.dll
#10617 0x00007ffefea624a8 in ntdll!RtlRaiseException () from C:\WINDOWS\SYSTEM32\ntdll.dll
#10618 0x00007ffefeab147e in ntdll!KiUserExceptionDispatcher () from C:\WINDOWS\SYSTEM32\ntdll.dll
#10619 0x00007ffefeab1ecf in ntdll!RtlRaiseNoncontinuableException () from C:\WINDOWS\SYSTEM32\ntdll.dll
#10620 0x00007ffefeb12636 in ntdll!RtlRaiseStatus () from C:\WINDOWS\SYSTEM32\ntdll.dll
#10621 0x00007ffefeac3f96 in ntdll!memset () from C:\WINDOWS\SYSTEM32\ntdll.dll
#10622 0x00007ffefea41040 in ntdll!RtlVirtualUnwind () from C:\WINDOWS\SYSTEM32\ntdll.dll
#10623 0x00007ffefea40e7b in ntdll!RtlVirtualUnwind () from C:\WINDOWS\SYSTEM32\ntdll.dll
#10624 0x00007ffefd481048 in RtlVirtualUnwind () from C:\WINDOWS\System32\kernel32.dll
#10625 0x00007ff7ab839a30 in __gnat_backtrace ()
#10626 0x00007ff7ab81e864 in system.traceback.call_chain ()
#10627 0x00007ff7ab81e8a7 in system.traceback.call_chain ()
#10628 0x00007ff7ab7b36bc in ada.exceptions.call_chain ()
#10629 0x00007ff7ab7b3a9b in ada.exceptions.complete_occurrence ()
#10630 0x00007ff7ab7b3adf in ada.exceptions.complete_and_propagate_occurrence ()
#10631 0x00007ff7ab7b3b4b in __gnat_raise_exception ()
#10632 0x00007ff7ab0c1cac in langkit_support.generic_api.unparsing.load_unparsing_config_from_buffer.template_kind.process (json=...)
    at D:\Dev\Tools\alire\cache\builds\langkit_support_25.0.0_7c5f4981\fa1231ebe196968a64642d6ac4243a6ca1a6e68e1b45d0188ae0c164eff585c3\langkit\support\langkit_support-generic_api-unparsing.adb:2208
#10633 0x00007ff7ab0c1e34 in langkit_support.generic_api.unparsing.load_unparsing_config_from_buffer.template_kind.process (json=...)
    at D:\Dev\Tools\alire\cache\builds\langkit_support_25.0.0_7c5f4981\fa1231ebe196968a64642d6ac4243a6ca1a6e68e1b45d0188ae0c164eff585c3\langkit\support\langkit_support-generic_api-unparsing.adb:2230
#10634 0x00007ff7ab0c1a45 in langkit_support.generic_api.unparsing.load_unparsing_config_from_buffer.template_kind (context=node_template, json=...)
    at D:\Dev\Tools\alire\cache\builds\langkit_support_25.0.0_7c5f4981\fa1231ebe196968a64642d6ac4243a6ca1a6e68e1b45d0188ae0c164eff585c3\langkit\support\langkit_support-generic_api-unparsing.adb:2249
#10635 0x00007ff7ab0c21be in langkit_support.generic_api.unparsing.load_unparsing_config_from_buffer.initial_state_for (node=..., json=..., context=...)
    at D:\Dev\Tools\alire\cache\builds\langkit_support_25.0.0_7c5f4981\fa1231ebe196968a64642d6ac4243a6ca1a6e68e1b45d0188ae0c164eff585c3\langkit\support\langkit_support-generic_api-unparsing.adb:2266
#10636 0x00007ff7ab0a3c30 in langkit_support.generic_api.unparsing.load_unparsing_config_from_buffer (language=0x7ff7ac6c8200 <libadalang.generic_impl.desc>, buffer=..., diagnostics=...)
    at D:\Dev\Tools\alire\cache\builds\langkit_support_25.0.0_7c5f4981\fa1231ebe196968a64642d6ac4243a6ca1a6e68e1b45d0188ae0c164eff585c3\langkit\support\langkit_support-generic_api-unparsing.adb:3399
#10637 0x00007ff7ab09bab7 in langkit_support.generic_api.unparsing.default_unparsing_configuration (language=0x7ff7ac6c8200 <libadalang.generic_impl.desc>)
    at D:\Dev\Tools\alire\cache\builds\langkit_support_25.0.0_7c5f4981\fa1231ebe196968a64642d6ac4243a6ca1a6e68e1b45d0188ae0c164eff585c3\langkit\support\langkit_support-generic_api-unparsing.adb:1752
#10638 0x00007ff7a94968ba in <gnatformat__configuration___elabs> () at D:/Dev/Tools/msys64/tmp/alr-jocr.tmp/gnatformat_25.0.0_79117be8/src/gnatformat-configuration.ads:440
#10639 0x00007ff7a9472375 in adainit () at b__gnatformat-ada_driver.adb:3381
#10640 0x00007ff7ab8a4590 in adainit () at b__gnatformat-ada_driver.adb:3434
#10641 main (argc=1, argv=0xd03de0, envp=0xd02550) at b__gnatformat-ada_driver.adb:3429
#10642 0x00007ff7a94610c9 in __tmainCRTStartup () at D:/W/B/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:236
#10643 0x00007ff7a9461416 in mainCRTStartup () at D:/W/B/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:122

x64dbg points out we get STATUS_BAD_FUNCTION_TABLE. MSDN says this means "A malformed function table was encountered during an unwind operation."

I would also like to add that I've encountered this same problem with the libadalang_tools package, but other alire packages I've tried work fine.

[mosteo]

To rule out any funny business with alr install, something you can try is:

1. alr get gnatformat
2. Enter gnatformat* folder
3. alr build

And try that executable, both manually and through alr run. I'm not optimistic but it would remove one variable.

[jcmoyer]

Sorry, I should have mentioned that is how I built it. However, I didn't try alr run. Let me rebuild and get back to you.

[jcmoyer]

I built gnatformat=26.0.0 (above was with 25.0.0) with gnat_native=15.2.1.

• alr run gnatformat.exe prints nothing, likewise with ./bin/gnatformat.exe
• gdb ./bin/gnatformat.exe and alr exec -- gdb ./bin/gnatformat.exe both produce the same stacktrace. It doesn't look like a stack overflow this time but it contains some odd addresses.
• x64dbg still reports STATUS_BAD_FUNCTION_TABLE

(gdb) bt
#0  0x00007ffb8e4c5369 in RaiseException () from C:\WINDOWS\System32\KernelBase.dll
#1  0x00007ff6cb43d6b1 in _Unwind_RaiseException ()
#2  0x00007ff6cb3a92a4 in ada.exceptions.exception_propagation.propagate_gcc_exception ()
#3  0x00007ff6cb3a92d7 in ada.exceptions.exception_propagation.propagate_exception ()
#4  0x00007ff6cb3a9fe7 in ada.exceptions.complete_and_propagate_occurrence ()
#5  0x00007ff6cb3aae29 in __gnat_rcheck_PE_Finalize_Raised_Exception ()
#6  0x00007ff6cba66215 in gnatcoll__json__json_arrayDA.cold ()
#7  0x0000000000bfc680 in ?? ()
#8  0x0000000000bfc370 in ?? ()
#9  0x00007ff6cbaa15d8 in system.soft_links.abort_undefer ()
#10 0x0000000000000001 in ?? ()
#11 0x0000000000bfdbb0 in ?? ()
#12 0x00000000035c25c0 in ?? ()
#13 0x00007ff6cb077e40 in langkit_support.generic_api.unparsing.load_unparsing_config_from_buffer.template_kind.process
    (json=...)
    at D:\Dev\Tools\alire\cache\builds\langkit_support_26.0.0_1745168f\d6e0f418fcdb20e0503e6fb7eef3f13a88e58660fec1d40199dd7221ccb78d4a\langkit\support\langkit_support-generic_api-unparsing.adb:2579
#14 0x00007ff6cb1060eb in langkit_support.generic_api.unparsing.load_unparsing_config_from_buffer.template_kind (
    context=<optimized out>, json=...)
    at D:\Dev\Tools\alire\cache\builds\langkit_support_26.0.0_1745168f\d6e0f418fcdb20e0503e6fb7eef3f13a88e58660fec1d40199dd7221ccb78d4a\langkit\support\langkit_support-generic_api-unparsing.adb:2598
#15 langkit_support.generic_api.unparsing.load_unparsing_config_from_buffer.initial_state_for (node=..., json=...,
    context=...)
    at D:\Dev\Tools\alire\cache\builds\langkit_support_26.0.0_1745168f\d6e0f418fcdb20e0503e6fb7eef3f13a88e58660fec1d40199dd7221ccb78d4a\langkit\support\langkit_support-generic_api-unparsing.adb:2615
#16 langkit_support.generic_api.unparsing.load_unparsing_config_from_buffer (
    language=language@entry=0x7ff6cc6bbc60 <libadalang.generic_impl.desc>, buffer=..., diagnostics=...,
    check_all_nodes=<optimized out>, check_all_nodes@entry=false)
    at D:\Dev\Tools\alire\cache\builds\langkit_support_26.0.0_1745168f\d6e0f418fcdb20e0503e6fb7eef3f13a88e58660fec1d40199dd7221ccb78d4a\langkit\support\langkit_support-generic_api-unparsing.adb:3875
#17 0x00007ff742cd9d5e in langkit_support.generic_api.unparsing.default_unparsing_configuration (
    language=0x7ff74428bc60 <libadalang.generic_impl.desc>)
    at D:\Dev\Tools\alire\cache\builds\langkit_support_26.0.0_1745168f\d6e0f418fcdb20e0503e6fb7eef3f13a88e58660fec1d40199dd7221ccb78d4a\langkit\support\langkit_support-generic_api-unparsing.adb:2089
#18 0x00007ff7412965f9 in <gnatformat__configuration___elabs> ()
    at ../gnatformat_26.0.0_a0a869fa/src/gnatformat-configuration.ads:465
#19 0x00007ff7411c84e5 in adainit () at b__gnatformat-ada_driver.adb:3982
#20 0x00007ff74307a590 in adainit () at b__gnatformat-ada_driver.adb:4185
#21 main (argc=1, argv=0xc93f90, envp=0xc925a0) at b__gnatformat-ada_driver.adb:4180
#22 0x00007ff7411c10d9 in __tmainCRTStartup () at D:/W/B/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:260
#23 0x00007ff7411c1456 in mainCRTStartup () at D:/W/B/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:129

[mosteo]

To remove further alr involvement, I'd suggest next to, after a pristine checkout, export the environment generated by alr printenv (alr help printenv should have examples on how to do it on Windows IIRC) and build directly with gprbuild.

[jcmoyer]

I get the same results as my previous comment with the following:

# starting with a completely empty cache
>alr get gnatformat && cd gnatformat_26.0.0_a0a869fa
# dependencies need to generate source files as part of their build - not sure how to avoid this
>alr build
>cd .. && del gnatformat_26.0.0_a0a869fa
>alr get gnatformat && cd gnatformat_26.0.0_a0a869fa
>alr printenv --wincmd > env.cmd
>call env.cmd
>gprbuild -j8 -Pgnat\gnatformat_driver.gpr
# <build succeeds>

[mosteo]

So it's not related to how Alire builds things. Given the discussion linked in comment #2056 (comment), it could be a bad interaction with MSYS2.

Maybe attempting with pristine settings is also worth a try, see ALIRE_SETTINGS_DIR in https://alire.ada.dev/docs/#relocating-your-settings . But if the bad interaction is from something in the base system seeping in, it won't make a difference.

[jcmoyer]

Deleting my settings yields the same result. I have a couple other ideas, but I will need to spend more time familiarizing myself with alire.

[jcmoyer]

I have a somewhat interesting update. I was able to produce a fully functional gnatformat binary by running alr get on each of the dependencies (recursively), editing each of their alire.tomls and pinning the dependencies to the directories created by alr get, and overriding the build type for each dependency under [gpr-set-externals] to produce dynamic libraries instead of static ones. This is coincidentally how the working gnatformat in msys2 is packaged.

Aside: This was an extremely annoying process. As far as I can tell, many of the packages involved have non-overridable defaults and building via a simple alr get gnatformat && cd <...> && alr build will always rewrite dependencies' alire.toml in the cache, even if you have modified it to test a different configuration. The non-overridable defaults prevent alr build --profiles=*=development from working - all or nearly all of the dependencies have release mode forced on. It would be nice if these packages respected your build profile, and similarly it would be nice if alr build supported a --dynamic flag to enable building shared libraries.

One thing I know for certain is that exception handling is broken in the default build configuration. langkit_support uses exceptions to break out of a deep recursive function and return a result. The first problematic usage appears here with Abort_Recursion.

https://github.com/AdaCore/langkit/blob/26.0/langkit/support/langkit_support-generic_api-unparsing.adb#L2503-L2603

If I remove Abort_Recursion and rewrite the function to use a boolean return instead, I can produce a partially working gnatformat binary that is able to print usage information. If I try to run it on a project it crashes in the next piece of code that uses exceptions (gnatcoll.utils.get_command_output).

So far I've tested the following configurations:

	debug	prod/release
static	crash	crash
relocatable	works	works

Building version 26.0.0 dependencies required additional adjustments to some alire.toml/gpr files so that I could make sure all dependencies were using the same build profile:

• vss_text alire.toml does not expose VSS_BUILD_PROFILE. Projects use Vss_Config instead of Vss_Text_Config.
• adasat alire.toml does not expose ADASAT_BUILD_MODE, ADASAT_LIBRARY_TYPE. -flto in prod flags causes the build to fail ("plugin needed to handle lto object" followed by linker failure).
• vss_extra alire.toml does not expose VSS_LIBRARY_TYPE, VSS_BUILD_PROFILE. Projects use Vss_Extras_Config instead of Vss_Extra_Config.
• gnatcoll_gmp alire.toml does not expose GNATCOLL_BUILD_MODE, LIBRARY_TYPE.
• gnatcoll_projects alire.toml does not expose GNATCOLL_BUILD_MODE, LIBRARY_TYPE.
• gprconfig_kb is missing a null gpr file in root, causing alr install to fail for gnatformat.

[mosteo]

• gnatcoll_gmp alire.toml does not expose GNATCOLL_BUILD_MODE, LIBRARY_TYPE.
• gnatcoll_projects alire.toml does not expose GNATCOLL_BUILD_MODE, LIBRARY_TYPE.

This is because they all should follow the same setting as used for the root gnatcoll. Pinging @AldanTanneo for confirmation.

[AldanTanneo]

all or nearly all of the dependencies have release mode forced on

This is because these are AdaCore libraries, most of which predate Alire; they are supposed be configured once, gprinstall-ed, and use from other gpr projects in installed form. The current way of doing things is not ideal, I'll grant you.

[AldanTanneo]

• gnatcoll_gmp alire.toml does not expose GNATCOLL_BUILD_MODE, LIBRARY_TYPE.
• gnatcoll_projects alire.toml does not expose GNATCOLL_BUILD_MODE, LIBRARY_TYPE.

This is because they all should follow the same setting as used for the root gnatcoll. Pinging @AldanTanneo for confirmation.

Well, Alire would error out if there were two different GNATCOLL_BUILD_MODE values in the dependency tree. So the idea is that only downstream users should set externals. By the way, not having externals declared in the manifest does not prevent you from setting them in the [gpr-set-externals] section (I think?). We make the choice to build them in release mode by default, and when possible we don't force it so you can still set the build mode with gpr externals in your project, or via environment variables.

For library type, it's even worse, because it's the same external name everywhere. The correct solution to this would be for Alire to gprinstall dependencies in a temporary folder, and then build with these, that way the externals for each library would be contained to their own build process.