On Monday 05 December 2022 08:39:11 Sam James wrote: > > On 4 Dec 2022, at 18:07, Luke Dashjr <l...@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?
Did that in February: https://bugzilla.kernel.org/show_bug.cgi?id=215557 > Or are you saying you want du to give you a nicer error message? I would like du to continue doing what it's doing, so I can still find the larger directories. :) Luke
