Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 2225696 - ahven: FTBFS in Fedora rawhide/f39
Summary: ahven: FTBFS in Fedora rawhide/f39
Alias: None
Product: Fedora
Classification: Fedora
Component: ahven
Version: 39
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Björn Persson
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2023-07-25 17:08 UTC by Fedora Release Engineering
Modified: 2024-01-08 08:34 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2024-01-08 08:34:10 UTC
Type: ---

Attachments (Terms of Use)
build.log (deleted)
2023-07-25 17:08 UTC, Fedora Release Engineering
no flags Details
root.log (deleted)
2023-07-25 17:09 UTC, Fedora Release Engineering
no flags Details
state.log (deleted)
2023-07-25 17:09 UTC, Fedora Release Engineering
no flags Details

Description Fedora Release Engineering 2023-07-25 17:08:52 UTC
ahven failed to build from source in Fedora rawhide/f39

For details on the mass rebuild see:
Please fix ahven at your earliest convenience and set the bug's status to
ASSIGNED when you start fixing it. If the bug remains in NEW state for 8 weeks,
ahven will be orphaned. Before branching of Fedora 40,
ahven will be retired, if it still fails to build.

For more details on the FTBFS policy, please visit:

Comment 1 Fedora Release Engineering 2023-07-25 17:08:57 UTC
Created attachment 1977565 [details]

file build.log too big, will only attach last 32768 bytes

Comment 2 Fedora Release Engineering 2023-07-25 17:09:01 UTC
Created attachment 1977566 [details]

file root.log too big, will only attach last 32768 bytes

Comment 3 Fedora Release Engineering 2023-07-25 17:09:04 UTC
Created attachment 1977567 [details]

Comment 4 Fedora Release Engineering 2023-08-16 07:54:33 UTC
This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle.
Changing version to 39.

Comment 5 Björn Persson 2023-08-20 11:33:17 UTC
What I've found so far is that Ahven's test suite intentionally raises an exception and tries to check that the exception was raised correctly, but exception propagation code somewhere in libgcc aborts the process instead of jumping to the exception handler.

Comment 6 Dennis van Raaij 2024-01-07 21:34:20 UTC
Closer inspection reveals that the abortion is caused by a failing assertion in `_Unwind_SetGR` (libgcc, unwind-dw2.c, line 295). The register size loaded from `dwarf_reg_size_table[index]` appears to be 0 while 8 is expected (at least for for x86_64).

Inspection of `dwarf_reg_size_table` near the assertion shows that the array has not been initialized:

    (gdb) info symbol 0x435a50
    dwarf_reg_size_table in section .bss of /home/user/ahven/gnat_linux/tester

    (gdb) x/17xb 0x435a50
    0x435a50 <dwarf_reg_size_table>:	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00
    0x435a58 <dwarf_reg_size_table+8>:	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00
    0x435a60 <dwarf_reg_size_table+16>:	0x00

However, further investigation reveals that there's another instance of `dwarf_reg_size_table`:

    (gdb) info address dwarf_reg_size_table
    Symbol "dwarf_reg_size_table" is static storage at address 0x7ffff7f15060.

This instance originates from the libgcc shared library and _has_ been initialized:

    (gdb) info symbol 0x7ffff7f15060
    dwarf_reg_size_table in section .bss of /lib64/

    (gdb) x/17xb 0x7ffff7f15060
    0x7ffff7f15060 <dwarf_reg_size_table>:	0x08	0x08	0x08	0x08	0x08	0x08	0x08	0x08
    0x7ffff7f15068 <dwarf_reg_size_table+8>:	0x08	0x08	0x08	0x08	0x08	0x08	0x08	0x08
    0x7ffff7f15070 <dwarf_reg_size_table+16>:	0x08

This immediately leads to the suspicion that the program is being linked incorrectly. Having a closer look at the build output reveals conflicting switches for `gnatbind`:

    /usr/bin/gnatbind -shared -o b__tester.adb <...> -static <...>
    /usr/bin/gnatbind -shared -o b__tap_tester.adb <...> -static <...>
    /usr/bin/gnatbind -shared -o b__perf_tester.adb <...> -static <...>

The `-static` switch is added via GPRbuild-file `gnat_linux/ahven_tests.gpr`.

Removing the `-static` switch - by either patching `ahven_tests.gpr` or overriding it using via Comfignat's `GNATBINDFLAGS` build parameter (i.e., add `GNATBINDFLAGS=-shared`) - solves the problem.

Comment 7 Björn Persson 2024-01-08 07:11:05 UTC
Thanks to Dennis for the analysis.

Passing -static to Gnatbind causes -static-libgcc to be passed to GCC for the linking. Overriding it with -shared causes -shared-libgcc to be used instead. The GCC manual has this to say about -shared-libgcc and -static-libgcc:

> There are several situations in which an application should use the
> shared ‘libgcc’ instead of the static version.  The most common of
> these is when the application wishes to throw and catch exceptions
> across different shared libraries.  In that case, each of the
> libraries as well as the application itself should use the shared
> ‘libgcc’.
> [...]
> However, if a library or main executable is supposed to throw or
> catch exceptions, you must link it using the G++ driver, or using
> the option ‘-shared-libgcc’, such that it is linked with the shared
> ‘libgcc’.

That's exactly what fails here: Ahven.Assert in the library raises an exception that Assertion_Tests.Test_Assert_Equal in the test program is supposed to catch. Thus I think it's clear that this use of -static is wrong.

Comment 8 Björn Persson 2024-01-08 08:34:10 UTC
Worked around with "GNATBINDFLAGS=-shared".

Note You need to log in before you can comment on or make changes to this bug.