Dear Maintainer,

Imagine my surprise when I encountered this on my sid VM:
-- >8 --
nab@kasan-test:/usr/local/share/zfs$ du -hd1 /var/tmp/test_results/
276K    /var/tmp/test_results/20220311T125225
4.0K    /var/tmp/test_results/20220315T223830
60K     /var/tmp/test_results/20220315T231319
132K    /var/tmp/test_results/20220315T230154
36K     /var/tmp/test_results/20220315T234726
124K    /var/tmp/test_results/20220315T225529
28K     /var/tmp/test_results/20220310T223917
16K     /var/tmp/test_results/20220315T223543
816K    /var/tmp/test_results/20220315T231704
112K    /var/tmp/test_results/20220310T231429
88K     /var/tmp/test_results/20220315T232426
12K     /var/tmp/test_results/20220311T125143
116K    /var/tmp/test_results/20220315T224954
120K    /var/tmp/test_results/20220310T222044
4.0M    /var/tmp/test_results/20220107T173340
120K    /var/tmp/test_results/20220310T221558
72K     /var/tmp/test_results/20220315T224919
16K     /var/tmp/test_results/20220315T223916
16K     /var/tmp/test_results/20220310T232110
16K     /var/tmp/test_results/20220310T233941
132K    /var/tmp/test_results/20220315T231443
16K     /var/tmp/test_results/20220315T223601
60K     /var/tmp/test_results/20220315T230938
28K     /var/tmp/test_results/20220310T223832
Aborted
-- >8 --

Imagine my further surprise when I could reproduce this, consistently,
across reboots (which fsck / clean) and du options,
but /not/ across cp -pr/tar/dump|restore!

The only way I can reproduce this is from the original filesystem image
(chrooted (1) or otherwise (bullseye host, so 8.32-4+b1)).

I would try to debug this, but I'm not gonna taint myself (sorry).
Nevertheless, I'm attaching a coredump (8.32-4.1), strace output,
ls -lRi /v/t/t_r, tar -c /v/t/t_r, and dump /v/t/t_r.

This link points to the image at hand (128G volsize,
10.2G/3.26G un-/compressed send predicted size,
4.4G raw lz4, 1.9G lz4+zstd ‒ very sparse):
https://foreign.nabijaczleweli.xyz/pub/du-SIGABRT-vda.lz4.zst

Just mounting it and doing du -hd1 mp/var/tmp/test_results
(or chrooting and doing the same from within) reproduces this for me
100% of the time.

Best,
наб

After some investigation, it was found that the abort is due to a
broken filesystem:


e2fsck 1.46.2 (28-Feb-2021)
Warning: skipping journal recovery because doing a read-only filesystem check.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Entry 'stdout' in
/var/tmp/test_results/20220107T162910/channel_program/lua_core/tst.memory_limit
(2753306) has an incorrect filetype (was 1, should be 2).
Fix? no

Entry 'stdout' in
/var/tmp/test_results/20220107T162910/channel_program/lua_core/tst.memory_limit
(2753306) is a link to directory
/var/tmp/test_results/20220107T173340/acl/off (2753307).
Clear? no

Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Inode 2753307 ref count is 5, should be 6.  Fix? no

Pass 5: Checking group summary information
Block bitmap differences:  -(18451--18516)
Fix? no

Free blocks count wrong (29962138, counted=29913053).
Fix? no

Free inodes count wrong (7795602, counted=7775599).
Fix? no


du-SIGABRT-vda: ********** WARNING: Filesystem still has errors **********

du-SIGABRT-vda: 68718/7864320 files (0.8% non-contiguous),
1495142/31457280 blocks


Depending on how filesystem errors should be handled in du, this bug should
either be closed or forwarded to someone who knows how to handle this
situation gracefully.