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.
Collin
[1]
https://cgit.git.savannah.gnu.org/cgit/hurd/gnumach.git/tree/vm/vm_map.c#n815
