How much memory do the various machines upon which you see this problem have?

We've seen this kind of problem before with another package (firefox).  See:

https://bugzilla.redhat.com/show_bug.cgi?id=2241690#c7

My laptop has 16 GB. gdb was using more than 10 GiB before I manually killed it.
For the CI, it barely has enough RAM to link projects like zed, so it probably has at least 16 GB too.

btdu is a pretty unsophisticated project so I don't think anything can justify gdb using more than 10 GiB of RAM.

Does this happen only with Fedora 43, or also on earlier releases?

As mentioned in the report:

> On my machine: 16.3-1.fc41
> On the CI: 16.3-1.fc43

I suppose this happens on all releases.

I've reproduced this problem.  Just attempting to load btdu's symbols into GDB (via "gdb btdu") is sufficient to trigger the "virtual memory exhausted" problem.

After a brief study of a core file, the problem appears to be in the D demangler in libiberty...

#8  0x0000556e5b63660c in malloc_failure (size=size@entry=-305654436) at ../../gdb/utils.c:671
#9  0x0000556e5b0ac22a in xrealloc (ptr=<optimized out>, size=size@entry=18446744073403897180)
    at ../../gdb/alloc.c:74
#10 0x0000556e5b8694a2 in string_need (s=0x7f376bffce50, n=18446744073403897180) at ../../libiberty/d-demangle.c:86
#11 0x0000556e5b86b3eb in string_appendn (p=0x7f376bffce50, 
    s=0x7f321ae3e010 "ae.utils.text.functor.formattingFunctor!(\"%s\", 250, ae.utils.text.functor.stringifiable!(ae.utils.functor.primitives.functor!(ae.utils.functor.composition.select!(ae.utils.functor.primitives.functor!("..., 
    n=18446744073556724361) at ../../libiberty/d-demangle.c:141
#12 string_appendn (p=0x7f376bffce50, 
    s=0x7f321ae3e010 "ae.utils.text.functor.formattingFunctor!(\"%s\", 250, ae.utils.text.functor.stringifiable!(ae.utils.functor.primitives.functor!(ae.utils.functor.composition.select!(ae.utils.functor.primitives.functor!("..., 
    n=18446744073556724361) at ../../libiberty/d-demangle.c:137
#13 dlang_parse_template (decl=decl@entry=0x7f376bffce50, 
    mangled=0x7f376af43299 "QDKwZQBVnTQEdZQDLkZQDSfFQGoZQBVmZQDMdZQDSyFQDJgZQBWgZ17__lambda_L40_C3_8TQDLeZQDNwZQBYnTQDRzTQDOcZQDOqZQDVlFQDVaZQBYtZQDYbFKQDXqMxAaQDXoZk", info=0x7f376bffdc20, len=18446744073709551615)
    at ../../libiberty/d-demangle.c:1917

Check out the size in frame #9!

This DIE appears to be problematic:

 <2><38063d>: Abbrev Number: 44 (DW_TAG_subprogram)
    <38063e>   DW_AT_low_pc      : 0x41c320
    <380646>   DW_AT_high_pc     : 0x4cd
    <38064a>   DW_AT_frame_base  : 1 byte block: 57 	(DW_OP_reg7 (rsp))
    <38064c>   DW_AT_linkage_name: (indirect string, offset: 0x267021): _D3std6format5write__T14formattedWriteTDFAxaZvTaTS2ae5utils4text7functor__T13stringifiableTSQBqQBqQBi10primitives__TQCaSQCsQCsQCk11composition__T3seqTSQDxQDxQDpQCh__TQDySQEqQEqQEnQEl__T17formattingFunctorVAyaa2_2573Vii250TQrZ15__lambda_L40_C3TQBmZ7FunctorTSQHzQHzQHrQGj__TQIaSQIsQIsQIpQIn__TQEcVQDma2_2573Vii250TSQKdQKdQKaQJy__TQJtTSQKxQKxQKpQJh__TQKyS4btdu2ui6curses6Curses4Wand__T8withAttrTSQNfQNfQNcQNa__TQMvTSQNzQNzQNrQMj__TQOaSQOsQOsQOkQMa__T6selectTSQPqQPqQPiQOa__TQPrSQQjQQjQQbQOt__T12valueFunctorTbZQrFbZ17__lambda_L143_C57TbZQLbTSQSvQSvQSnQRf__TQSwSQToQToQTlQTj__T5fmtIfVQOlnTbTPFNaNbNiNfZQPdTSQVhQVhQUzQTr__TQViSQKkQKi7browser7Browser6updateMFZ__T17__lambda_L1185_C4TQSeTSQYiQYiQYfQYd__TQXyTSQZcQZcQYuQXm__TQZdSQZvQZvQZnQXd__TQLdTQKzTSQBAtQBAuQBAnQZg__TQBAxSQBBqQBBrQBBpQBBo__TQIgVQWonTbTSQBCvQBCwQBCpQBBi__TQBDaSQBDtQBDuQBDnQBCg__TQNoTSQBErQBEsQBEqQBEp__TQBElTSQBFqQBFrQBFkQBEd__TQBFvSQBGoQBGpQBGiQBDz__TQBDqTSQBHnQBHoQBHhQBGa__TQBHsSQBIlQBImQBIkQBIj__TQBDzVQBDka2_2573Vii250TSQBKcQBKdQBKbQBKa__TQBJwTSQBLbQBLcQBKvQBJo__TQBLgSQBAjQBAiQBAjQBAgQBAd__TQBAcTQBHcTSQBNhQBNiQBNgQBNf__TQBNbTSQBOgQBOhQBOaQBMt__TQBOlSQBDoQBDnQBDoQBDlQBDi__TQBDhTQBKhZQBDrMFEQBFcQBFbQBFcQBEzQBEw9AttributebKQBLzZ19__lambda_L503_C20_1TPSQBHlQBHkQBHlQBHiQBHfTQDfTbTSQBUdQBUeQBUcQBUb__TQBTxTSQBVcQBVdQBUwQBTp__TQBVhSQBWaQBWbQBVuQBTl__TQBTcTQBTcZ3funTQBTmZQBPyZQBWtFQCwZ13StringifiableZQBRcZQBXxFQKwZQBeTQBTkZQBMuMFQJdbQBTzQMwQBUgZ17__lambda_L503_C20TQIfTQKrTbTSQCBpQCBqQCBoQCBn__TQCBjTSQCCoQCCpQCCiQCBb__TQCCtSQCDmQCDnQCDgQCAx__TQCAoTQCAoTSQCEqQCErQCEkQCDd__TQCEvSQCFoQCFpQCFnQCFm__TQCBcVQCAna2_2573Vii250TQTyZ17__lambda_L40_C3_1TQUwZQCArTQCEpZQLnTQCEyTQEkTQCFhZQCBtZQCIoFQHfZQLvZQCClZQCJgFQZkZQMnZ17__lambda_L40_C3_3TQBBlZQCEcTQCIaTQBEpZQPdTQBEyTQCItTQBFiZQCFkZQCMfFQBHuZQPnZQBWuFQBJhZ19__lambda_L143_C57_1TQBKiZQCHoTSQCPjQCPkQCPdQCNw__TQCPoSQCQhQCQiQCQbQCOu__TQCAcTQBHeZQCAmFQBHoZ19__lambda_L143_C57_2TQBIpZQCLgZQBYxFNibQBQoQEeZQWnTQBRaZQCMkTSQCUfQCUgQCTzQCSs__TQCUkSQCVdQCVeQCVcQCVb__TQCBtVQCQcnTbTQBTpTQHgZQCCpFNibQBUgQHwZQBAfTQIfZQCQcZQBAtTQCImTQBXoTQEhZQCRaZQCXvFQBZyZQBBdZQCCaMFQCTqQCBmbSQCOjQCOiQCEbQCDx13ScrollContextPSQCPq5paths11BrowserPathZ20__lambda_L1195_C76_1TQBxZQCVqZQCJhFNibQCJbQCIqZQBGyTQCJpZQCWwTSQDErQDEsQDElQDDe__TQDEwSQDFpQDFqQDFoQDFn__TQCMfVQDAonTbTQCMeTQCLuZQCNcFNibQCMwQCMlZQBKtTQCMvZQDArZQBLiTQCTbTQCQbTQEkZQDBpZQDIkFQCVqZQBLsZQCXeMFQBTnbQCXfZ19__lambda_L503_C20_2TQBSlTQBUyTbTSQDLxQDLyQDLwQDLv__TQDLrTSQDMwQDMxQDMqQDLj__TQDNbSQDNuQDNvQDNoQDLf__TQDKwTSQDOtQDOuQDOnQDNg__TQDOySQDPrQDPsQDPqQDPp__TQDLfVQDKqa2_2573Vii250TQDEdZ17__lambda_L40_C3_7TQDFcZQDKwZQBVnTQEdZQDLkZQDSfFQGoZQBVmZQDMdZQDSyFQDJgZQBWgZ17__lambda_L40_C3_8TQDLeZQDNwZQBYnTQDRzTQDOcZQDOqZQDVlFQDVaZQBYtZQDYbFKQDXqMxAaQDXoZk
    <380650>   DW_AT_name        : (indirect string, offset: 0x64678): formattedWrite<void delegate(slice<const(char)>), char, Stringifiable>
    <380654>   DW_AT_decl_file   : 185
    <380655>   DW_AT_decl_line   : 527
    <380657>   DW_AT_type        : <0x1b4d4>
    <38065b>   DW_AT_external    : 1

I'm investigating further...

This bug can be reproduced without needing to build btdu...

Start gdb and do:

(gdb) set lang d
(gdb) demangle _D3std6format5write__T14formattedWriteTDFAxaZvTaTS2ae5utils4text7functor__T13stringifiableTSQBqQBqQBi10primitives__TQCaSQCsQCsQCk11composition__T3seqTSQDxQDxQDpQCh__TQDySQEqQEqQEnQEl__T17formattingFunctorVAyaa2_2573Vii250TQrZ15__lambda_L40_C3TQBmZ7FunctorTSQHzQHzQHrQGj__TQIaSQIsQIsQIpQIn__TQEcVQDma2_2573Vii250TSQKdQKdQKaQJy__TQJtTSQKxQKxQKpQJh__TQKyS4btdu2ui6curses6Curses4Wand__T8withAttrTSQNfQNfQNcQNa__TQMvTSQNzQNzQNrQMj__TQOaSQOsQOsQOkQMa__T6selectTSQPqQPqQPiQOa__TQPrSQQjQQjQQbQOt__T12valueFunctorTbZQrFbZ17__lambda_L143_C57TbZQLbTSQSvQSvQSnQRf__TQSwSQToQToQTlQTj__T5fmtIfVQOlnTbTPFNaNbNiNfZQPdTSQVhQVhQUzQTr__TQViSQKkQKi7browser7Browser6updateMFZ__T17__lambda_L1185_C4TQSeTSQYiQYiQYfQYd__TQXyTSQZcQZcQYuQXm__TQZdSQZvQZvQZnQXd__TQLdTQKzTSQBAtQBAuQBAnQZg__TQBAxSQBBqQBBrQBBpQBBo__TQIgVQWonTbTSQBCvQBCwQBCpQBBi__TQBDaSQBDtQBDuQBDnQBCg__TQNoTSQBErQBEsQBEqQBEp__TQBElTSQBFqQBFrQBFkQBEd__TQBFvSQBGoQBGpQBGiQBDz__TQBDqTSQBHnQBHoQBHhQBGa__TQBHsSQBIlQBImQBIkQBIj__TQBDzVQBDka2_2573Vii250TSQBKcQBKdQBKbQBKa__TQBJwTSQBLbQBLcQBKvQBJo__TQBLgSQBAjQBAiQBAjQBAgQBAd__TQBAcTQBHcTSQBNhQBNiQBNgQBNf__TQBNbTSQBOgQBOhQBOaQBMt__TQBOlSQBDoQBDnQBDoQBDlQBDi__TQBDhTQBKhZQBDrMFEQBFcQBFbQBFcQBEzQBEw9AttributebKQBLzZ19__lambda_L503_C20_1TPSQBHlQBHkQBHlQBHiQBHfTQDfTbTSQBUdQBUeQBUcQBUb__TQBTxTSQBVcQBVdQBUwQBTp__TQBVhSQBWaQBWbQBVuQBTl__TQBTcTQBTcZ3funTQBTmZQBPyZQBWtFQCwZ13StringifiableZQBRcZQBXxFQKwZQBeTQBTkZQBMuMFQJdbQBTzQMwQBUgZ17__lambda_L503_C20TQIfTQKrTbTSQCBpQCBqQCBoQCBn__TQCBjTSQCCoQCCpQCCiQCBb__TQCCtSQCDmQCDnQCDgQCAx__TQCAoTQCAoTSQCEqQCErQCEkQCDd__TQCEvSQCFoQCFpQCFnQCFm__TQCBcVQCAna2_2573Vii250TQTyZ17__lambda_L40_C3_1TQUwZQCArTQCEpZQLnTQCEyTQEkTQCFhZQCBtZQCIoFQHfZQLvZQCClZQCJgFQZkZQMnZ17__lambda_L40_C3_3TQBBlZQCEcTQCIaTQBEpZQPdTQBEyTQCItTQBFiZQCFkZQCMfFQBHuZQPnZQBWuFQBJhZ19__lambda_L143_C57_1TQBKiZQCHoTSQCPjQCPkQCPdQCNw__TQCPoSQCQhQCQiQCQbQCOu__TQCAcTQBHeZQCAmFQBHoZ19__lambda_L143_C57_2TQBIpZQCLgZQBYxFNibQBQoQEeZQWnTQBRaZQCMkTSQCUfQCUgQCTzQCSs__TQCUkSQCVdQCVeQCVcQCVb__TQCBtVQCQcnTbTQBTpTQHgZQCCpFNibQBUgQHwZQBAfTQIfZQCQcZQBAtTQCImTQBXoTQEhZQCRaZQCXvFQBZyZQBBdZQCCaMFQCTqQCBmbSQCOjQCOiQCEbQCDx13ScrollContextPSQCPq5paths11BrowserPathZ20__lambda_L1195_C76_1TQBxZQCVqZQCJhFNibQCJbQCIqZQBGyTQCJpZQCWwTSQDErQDEsQDElQDDe__TQDEwSQDFpQDFqQDFoQDFn__TQCMfVQDAonTbTQCMeTQCLuZQCNcFNibQCMwQCMlZQBKtTQCMvZQDArZQBLiTQCTbTQCQbTQEkZQDBpZQDIkFQCVqZQBLsZQCXeMFQBTnbQCXfZ19__lambda_L503_C20_2TQBSlTQBUyTbTSQDLxQDLyQDLwQDLv__TQDLrTSQDMwQDMxQDMqQDLj__TQDNbSQDNuQDNvQDNoQDLf__TQDKwTSQDOtQDOuQDOnQDNg__TQDOySQDPrQDPsQDPqQDPp__TQDLfVQDKqa2_2573Vii250TQDEdZ17__lambda_L40_C3_7TQDFcZQDKwZQBVnTQEdZQDLkZQDSfFQGoZQBVmZQDMdZQDSyFQDJgZQBWgZ17__lambda_L40_C3_8TQDLeZQDNwZQBYnTQDRzTQDOcZQDOqZQDVlFQDVaZQBYtZQDYbFKQDXqMxAaQDXoZk

I have not been able to demonstrate either an infinite loop nor infinite recursion.

I have investigated by placing a breakpoint on the return statement for dlang_backref in libiberty/d-demangle.c and then setting up the following command on that breakpoint:

(top-gdb) info break 3
Num     Type           Disp Enb Address            What
3       breakpoint     keep y   0x0000000000a7a205 in dlang_backref at /mesquite2/sourceware-git/f42-demangle/bld/../../worktree-demangle/libiberty/d-demangle.c:361
	breakpoint already hit 552872 times
        silent
        echo \n
        p qpos
        p mangled
        p *ret
        if qpos > $biggest
          set $biggest=qpos
        end
        c

I also did "set $biggest=0" prior to issuing the demangle command shown above.

Interrupting top gdb and copying the incremental output to a text editor prior to continuing again reveals that progress is being made through the input string, albeit slowly, and slower and slower the longer the program is allowed to continue.

The time and space complexity is very bad. As shown in an earlier comment, the demangler is, prior to dying with an internal error, requesting 18.4 exobytes of RAM, an absurd amount.

I think that the D demangler should be forced to return/throw an error condition when presented with an input that causes its constructed output to exceed a certain limit.

However, I'm also skeptical that a 2696 character linkage name containing 441 backreferences is correct. I recommend that the reporter (also) file a D compiler bug for this matter.

I plan to look at this problem some more, though not very quickly or soon.  I'll attempt to make the D demangler return an error as discussed earlier.

Out of interest, I tried using this tool: https://github.com/dlang/tools/blob/master/ddemangle.d which is a D specific demangling tool created by the D project itself.  This tool also failed after a while with:

  core.exception.OutOfMemoryError@core/exception.d(729): Memory allocation failed

which is a good thing I think -- if the D project's demangler had managed to demangle it then that would indicate we might need to really fix the demangler.  As it is, it would appear that the symbol is likely invalid.

This message is a reminder that Fedora Linux 42 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 42 on 2026-05-13.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '42'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 42 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

I posted a fix for this issue here: https://inbox.sourceware.org/gcc-patches/dec1df5fbbd92283fe4d1a097063ea8771bea88d.1776181297.git.aburgess@redhat.com/

If/when this is merged to gcc I can backport this to upstream binutils-gdb.  After that we can potentially backport this to some Fedora branches.  Due to F42 EOL it is unlikely to land there, but merging this to other active branches shouldn't be an issue.

Fedora Linux 42 entered end-of-life (EOL) status on 2026-05-27.

Fedora Linux 42 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.

I got this fix merged into the gcc repository, and have posted the patch to back-port the fix into the binutils-gdb repository:

https://inbox.sourceware.org/binutils/ff87d7cb74f9d3d3b81aeca0a979d3dcc1531567.1781002240.git.aburgess@redhat.com

Once this is merged into binutis-gdb then we can make a plan for back-porting to Fedora.

FEDORA-2026-3a8f9747f8 (gdb-17.2-2.fc44) has been submitted as an update to Fedora 44.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-3a8f9747f8

FEDORA-2026-2c86563178 (gdb-17.2-2.fc43) has been submitted as an update to Fedora 43.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-2c86563178

FEDORA-2026-2c86563178 has been pushed to the Fedora 43 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-2c86563178`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-2c86563178

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2026-3a8f9747f8 has been pushed to the Fedora 44 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-3a8f9747f8`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-3a8f9747f8

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2026-2c86563178 (gdb-17.2-2.fc43) has been pushed to the Fedora 43 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2026-3a8f9747f8 (gdb-17.2-2.fc44) has been pushed to the Fedora 44 stable repository.
If problem still persists, please make note of it in this bug report.