> On 4 Dec 2022, at 18:07, Luke Dashjr <luke@dashjr.org> wrote:
> 
> Version: sys-apps/coreutils-9.1-r1 (Gentoo)
> 
> Context: Linux has a long-standing bug which leads to ext4 RAM dishs (zram
> specifically) getting corrupted randomly. This manifests as various
> newfstatat calls returning -1 errno=EUCLEAN (Structure needs cleaning).
> 
> The `du` tool, when it encounters them, prints an error as expected, but later
> on aborts at:
> #4  0x00007ffff7d4d3dc in __GI_abort () at abort.c:79
> #5  0x000000010000ba08 in leave_dir (fts=fts@entry=0x100042680,
> ent=ent@entry=0x100071630)
>    at lib/fts-cycle.c:136
> #6  0x000000010000bd00 in fts_build (sp=sp@entry=0x100042680,
> type=type@entry=3) at lib/fts.c:1326
> #7  0x000000010000ce7c in rpl_fts_read (sp=0x100042680) at lib/fts.c:925
> #8  0x0000000100004864 in du_files (files=<optimized out>,
> bit_flags=<optimized out>) at src/du.c:691
> #9  0x0000000100005cfc in main (argc=<optimized out>, argv=<optimized out>) at
> src/du.c:1123
> 
> (I am not certain if the fstatat return value is related to the later abort,
> because I couldn't find a way to get gdb to break only when fstatat returns
> nonzero)

I may well be missing something, but shouldn't you be reporting this to the kernel
folks instead?

Or are you saying you want du to give you a nicer error message?