Bug 2432586

After changing coredump limit, a coredump is created, but it reports the host package version:

           PID: 87525 (ld)
           UID: 0 (root)
           GID: 0 (root)
        Signal: 11 (SEGV)
     Timestamp: Sat 2026-01-24 20:50:41 CET (3min 58s ago)
  Command Line: ld -r -b binary -z noexecstack xputty_logo.png -o t3.o
    Executable: /usr/bin/ld.bfd
 Control Group: /machine.slice/machine-6bf11709e5494284a7c1ffbe69fe14df.scope/payload
          Unit: machine-6bf11709e5494284a7c1ffbe69fe14df.scope
         Slice: machine.slice
       Boot ID: 933c0d1c4dd44b2d842e1c1e26cb84c9
    Machine ID: f334e89d9e9b4f1ebf6c14577bc78978
      Hostname: 6bf11709e5494284a7c1ffbe69fe14df
       Storage: /var/lib/systemd/coredump/core.ld.0.933c0d1c4dd44b2d842e1c1e26cb84c9.87525.1769284241000000.zst (present)
  Size on Disk: 74.1K
       Package: binutils/2.43.1-14.fc41
      build-id: 488efd0d1ec4b549dccca5737f3176d7a8e2e499
       Message: Process 87525 (ld) of user 0 dumped core.
                
                Module /usr/bin/ld.bfd from rpm binutils-2.43.1-14.fc41.x86_64
                Stack trace of thread 37:
                #0  0x0000559b3f8b01ac map_input_to_output_sections.isra.0 (/usr/bin/ld.bfd + 0x4b1ac)
                #1  0x0000559b3f884dd8 gldi386pep_list_options.lto_priv.0 (/usr/bin/ld.bfd + 0x1fdd8)
                #2  0x0000559b3f868934 main (/usr/bin/ld.bfd + 0x3934)
                #3  0x00007f749df27681 n/a (/usr/lib64/libc.so.6 + 0x3681)
                #4  0x00007f749df27798 n/a (/usr/lib64/libc.so.6 + 0x3798)
                #5  0x0000559b3f86a7d5 main (/usr/bin/ld.bfd + 0x57d5)
                ELF object binary architecture: AMD x86-64

Bactrace:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000559b3f8b01ac in ldelf_after_open.constprop.0 (use_libpath=1, native=1, elfsize=64, prefix=0x559b3f8c5afd "/usr", is_freebsd=0, is_linux=1) at ../../ld/ldelf.c:1333                 
1333		    elf_section_type (s) = SHT_NOTE;
(gdb) bt
#0  0x0000559b3f8b01ac in ldelf_after_open.constprop.0 (use_libpath=1, native=1, elfsize=64, prefix=0x559b3f8c5afd "/usr", is_freebsd=0, is_linux=1) at ../../ld/ldelf.c:1333
#1  0x0000559b3f884dd8 in ldemul_after_open () at ../../ld/ldemul.c:80
#2  lang_process () at ../../ld/ldlang.c:8563
#3  0x0000559b3f868934 in main (argc=9, argv=<optimized out>) at ../../ld/ldmain.c:958

Noticed the same for my mupdf builds in rawhide. Further info:

Build worked during the mass rebuild, i.e. with binutils from that buildroot.

Build works on aarch64 and ppc64le (koji scratch), but no other arch:

https://koji.fedoraproject.org/koji/taskinfo?taskID=141553683

In terms of fedora/dist-git rawhide commits, I bisected this to:

27063804ceed9b9d7b9c1628ac8a6725d45d8a02 is the first bad commit
commit 27063804ceed9b9d7b9c1628ac8a6725d45d8a02 (origin/rawhide, origin/main, origin/HEAD, rawhide)
Author: Nick Clifton <nickc>
Date:   Mon Jan 19 10:29:29 2026 +0000

    Rebase to commit ba5838a98fb

Think this should be https://sourceware.org/PR33780 and it's fixed already upstream.

(In reply to Sam James from comment #5)
> Think this should be https://sourceware.org/PR33780 and it's fixed already
> upstream.

Yep, with that commit on top of current rawhide, I don't have that segfault any more on x86_64. (Haven't checked the contents of the .o, though.)

No more issue with the latest build : binutils-2.45.90-1.fc44.

*** Bug 2435975 has been marked as a duplicate of this bug. ***

I can confirm that binutils-2.45.90-1.fc44.x86_64 solves my package's FTBFS in local mock.

The update is sitting in testing, though, due to some CI hick-up. Would be nice to have this in F44 no matter the branching.

Please note that the build fixing this has been unpushed because of the branch event. Please rebuild and resubmit.

We have binutils-2.46-1 in f44 buildroot, so I expect this issue is fixed now.