tests/cut/cut-huge-range.sh appears to consistently fail when building coreutils with gcc-16. This happens only on aarch64. Reproducible: Always Steps to Reproduce: 1. Scratch build coreutils against the f44-build-side-124978 side tag koji build --scratch f44-build-side-124978 coreutils-9.9-1.fc44.src.rpm Actual Results: aarch64 build fails due to one test failing: + printf '%s\n' 'diff -u /dev/null err' $'--- /dev/null\t1970-01-01' $'+++ err\t1970-01-01' diff -u /dev/null err --- /dev/null 1970-01-01 +++ err 1970-01-01 + sed 's/^/+/' err +cut: memory exhausted + return 1 + case $? in + return 1 + fail=1 + Exit 1 + set +e + exit 1 + exit 1 + remove_tmp_ + __st=1 + cleanup_ + : + test '' = yes + cd /builddir/build/BUILD/coreutils-9.9-build/coreutils-9.9/separate + chmod -R u+rwx /builddir/build/BUILD/coreutils-9.9-build/coreutils-9.9/separate/gt-cut-huge-range.sh.YbJy + rm -rf /builddir/build/BUILD/coreutils-9.9-build/coreutils-9.9/separate/gt-cut-huge-range.sh.YbJy + exit 1 FAIL tests/cut/cut-huge-range.sh (exit status: 1) Expected Results: Test does not fail. Additional Information: Please do not build into the side tag since it's only to test the gcc 16 rebase for rawhide, only do a scratch build. At first glance it looked like an infrastructure issue to me, but I'm pretty sure I may have missed something re. the requirements of the test, especially since the aarch64 failure is reproducible.
It would be a good to include a bit more output from test-suite.log to verify the calculated $vm value was sane. Does the following adjustment avoid the issue? That shouldn't be needed though. Does `getconf PAGE_SIZE` work on that platform, because we use a fallback of 4096 which may not be appropriate for the platform. diff --git a/tests/cut/cut-huge-range.sh b/tests/cut/cut-huge-range.sh index 4bd1b129d..c0b7cc2e4 100755 --- a/tests/cut/cut-huge-range.sh +++ b/tests/cut/cut-huge-range.sh @@ -22,6 +22,7 @@ getlimits_ vm=$(get_min_ulimit_v_ returns_ 0 cut -b1 /dev/null) \ || skip_ 'shell lacks ulimit, or ASAN enabled' +vm=$(($vm+1000)) # Ensure we can cut up to our sentinel value. CUT_MAX=$(expr $UINTMAX_MAX - 1) || framework_failure_
Sorry, I should have linked to the failure log: https://copr.fedorainfracloud.org/coprs/siddhesh/mbp-gcc-snapshot-latest/build/9940990/ https://download.copr.fedorainfracloud.org/results/siddhesh/mbp-gcc-snapshot-latest/fedora-rawhide-aarch64/09940990-coreutils/builder-live.log.gz I'll try the workaround and let you know.
It does work with the patch you suggested: https://koji.fedoraproject.org/koji/taskinfo?taskID=140281595 I don't see why `getconf PAGESIZE` shouldn't work on aarch64, but I think we have 64k pages on aarch64, so obviously something is awry.
one could correlate the page size with something like `grep -Fi PAGESIZE /proc/$$/smaps | sort -u` But the logs show getconf returns 4096. I can't think of any other workaround for now, so I suggest applying that change as a patch to rawhide (I'll do the same upstream).
I know next to nothing about the malloc internals, but could it be due to this recent change? https://sourceware.org/git/?p=glibc.git;a=commit;h=321e1fc73f53081d92ba357cdd48c56b79292020 > The benefit is that on MORECORE() invocation, we extend the heap by 2MB instead of 4KB [on aarch64]
Oh interesting. Something to keep in mind for the `ulimit -v ...` limit determination in coreutils tests
Thank you all for the analysis! The fix is building now: https://koji.fedoraproject.org/koji/taskinfo?taskID=141060076
FEDORA-2026-12d51a2112 (coreutils-9.9-2.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-12d51a2112
FEDORA-2026-12d51a2112 (coreutils-9.9-2.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.