On 06/11/2025 08:15, Collin Funk wrote:
Pádraig Brady <[email protected]> writes:
On 05/11/2025 23:28, Bruno Haible wrote:
On Hurd 2025/x86_64, wc/wc-total hangs.
Hangs are really very bad of course.
I don't have access to Hurf.
Doe the following avoid the hang at least?
cheers,
Padraig
diff --git a/tests/wc/wc-total.sh b/tests/wc/wc-total.sh
index 1622962c5..41fc2384d 100755
--- a/tests/wc/wc-total.sh
+++ b/tests/wc/wc-total.sh
@@ -42,10 +42,10 @@ compare exp out || fail=1
wc --total=always 2b > out || fail=1
test "$(wc -l < out)" = 2 || fail=1
-if truncate -s 2E big; then
+if timeout 10 truncate -s 2E big; then
if test "$UINTMAX_MAX" = '18446744073709551615'; then
# Ensure overflow is diagnosed
- returns_ 1 wc --total=only -c big big big big big big big big \
+ returns_ 1 timeout 10 wc --total=only -c big big big big big big big big \
> out || fail=1
# Ensure total is saturated
@@ -53,7 +53,7 @@ if truncate -s 2E big; then
compare exp out || fail=1
# Ensure overflow is ignored if totals not shown
- wc --total=never -c big big big big big big big big || fail=1
+ timeout 10 wc --total=never -c big big big big big big big big || fail=1
fi
fi
Sadly, this doesn't resolve the hang.
Over SSH I ran the following:
$ truncate -s 2E big
$ wc --total=only -c big big big big big big big big
Timeout, server localhost not responding.
In my QEMU window I saw the following message printed twice:
$ no more room in ([memory address]) (ext2fs)
Looking at where that is printed, it looks like the file system cannot
find memory to map [1]. It seems like a bug, since all we are doing is
seeking and reading IO_BUFSIZE.
Should we just check if we are on Hurd and skip the test? I can send
them a bug report for this later, since it can be easily reproduced.
For a kernel panic like that it would be best to just skip on hurd.
thanks,
Padraig
