Fedora Account System
Red Hat Associate
Red Hat Customer
ncdu 2.10.0 crashes (SIGABRT) when scanning /home/okasion and certain subdirectories under ~/Music. The crash is a Zig panic: thread panic: integer does not fit in destination type Environment ----------- - OS: Fedora 44 (x86_64) - Package: ncdu-2.10.0-3.fc44 - Binary: /usr/bin/ncdu (Zig-based ncdu 2.x from BratishkaErik/ncdu) Steps to Reproduce ------------------ 1. Run: ncdu /home/okasion → crashes during scan (DrKonqi / coredump) Non-interactive reproduction: 2. Run: ncdu -o /dev/null /home/okasion → same panic, exit 134 (SIGABRT) Narrower reproduction: 3. Run: ncdu -o /dev/null /home/okasion/Music → crashes 4. These Music subdirectories crash individually: - .../2010.07.31 House set of the Embodiment of Scarlet Devil/ - .../2013.08.12 [SDHC-0038] 妖夢 -YOUMU- [C84]/ - .../(C85) Alstroemeria Records — DECADE OF EXPOSE (東方) [ARCD0042] (flac+scans)/ 5. In the Alstroemeria album, crash localizes to the "Scans/" subfolder (ASCII filenames: Obi.JPG, Booklet01.JPG, etc.) 6. Other albums with Japanese filenames scan fine, e.g.: .../2011.03.22 House set of ''Perfect Cherry Blossom''/ So this does not appear to be a UTF-8 filename issue. Expected -------- ncdu completes the scan and shows the disk usage UI (or writes export file). Actual ------ Process aborts with Zig panic "integer does not fit in destination type". systemd-coredump records SIGABRT for /usr/bin/ncdu. Additional context ------------------ - /home/okasion total size: ~138 GB - ~/Music: ~8 GB, 375 files - Crash appears to be an integer overflow in the Zig scanner (stack includes scan.Thread.run, debug.defaultPanic), not a permission or symlink issue. - Workaround: ncdu --exclude /home/okasion/Music /home/okasion or use du/dust/ncdu 1.x coredumpctl info ncdu output: 308995 files / 104.1 GiB #1: /home/okasion/.cache/gopls/181aec27/c6 thread 56472 panic: integer does not fit in destination type ???:?:?: 0x5595ce575728 in ??? (???) ???:?:?: 0x5595ce504782 in ??? (???) ???:?:?: 0x5595ce506825 in ??? (???) ???:?:?: 0x5595ce5018ba in ??? (???) ???:?:?: 0x7fa068ee6680 in __libc_start_call_main (/lib64/libc.so.6) ???:?:?: 0x7fa068ee6797 in __libc_start_main_alias_2 (/lib64/libc.so.6) ???:?:?: 0x5595ce5014f0 in ??? (???) Aborted (core dumped) ncdu -o /dev/null /home/okasion okasion@entropy:~/Code/golab/ozyup$ Reproducible: Always Steps to Reproduce: ncdu 2.10.0 crashes (SIGABRT) when scanning /home/okasion and certain subdirectories under ~/Music. The crash is a Zig panic: thread panic: integer does not fit in destination type Environment ----------- - OS: Fedora 44 (x86_64) - Package: ncdu-2.10.0-3.fc44 - Binary: /usr/bin/ncdu (Zig-based ncdu 2.x from BratishkaErik/ncdu) Steps to Reproduce ------------------ 1. Run: ncdu /home/okasion → crashes during scan (DrKonqi / coredump) Non-interactive reproduction: 2. Run: ncdu -o /dev/null /home/okasion → same panic, exit 134 (SIGABRT) Narrower reproduction: 3. Run: ncdu -o /dev/null /home/okasion/Music → crashes 4. These Music subdirectories crash individually: - .../2010.07.31 House set of the Embodiment of Scarlet Devil/ - .../2013.08.12 [SDHC-0038] 妖夢 -YOUMU- [C84]/ - .../(C85) Alstroemeria Records — DECADE OF EXPOSE (東方) [ARCD0042] (flac+scans)/ 5. In the Alstroemeria album, crash localizes to the "Scans/" subfolder (ASCII filenames: Obi.JPG, Booklet01.JPG, etc.) 6. Other albums with Japanese filenames scan fine, e.g.: .../2011.03.22 House set of ''Perfect Cherry Blossom''/ So this does not appear to be a UTF-8 filename issue. Actual Results: ncdu completes the scan and shows the disk usage UI (or writes export file). Actual ------ Process aborts with Zig panic "integer does not fit in destination type". systemd-coredump records SIGABRT for /usr/bin/ncdu. Expected Results: list of dirs and space used... ncdu working fine
Would you be able to send me the output of: $ strace -v ncdu -o /dev/null <folder that reproduces the issue> as this might show some bad values being returned for some directories/files.
This looks to be the same as this upstream issue: https://github.com/BratishkaErik/ncdu/issues/3 It's fixed in 2.11.0. I'm working on packaging that version (#2497359).
FEDORA-2026-38db2b11c3 (ncdu-2.11.0-1.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2026-38db2b11c3
FEDORA-2026-9479d5196e (ncdu-2.11.0-1.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-9479d5196e
FEDORA-2026-9479d5196e 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-9479d5196e` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-9479d5196e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-38db2b11c3 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-38db2b11c3` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-38db2b11c3 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
I was able to reproduce the problem with ncdu 2.10.0 using the steps in https://github.com/BratishkaErik/ncdu/issues/3#issuecomment-4937620054. The problem is fixed with 2.11.0.
FEDORA-2026-38db2b11c3 (ncdu-2.11.0-1.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-9479d5196e (ncdu-2.11.0-1.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.