On 2020-04-16 21:36, Paul Eggert wrote: > On 4/16/20 9:32 AM, Bernhard Voelker wrote: > >> okay, strange - eventually I have time to try the same with du(1) later this >> evening. > > Yes, it is strange. I tried 'find' and the Gnulib patch fixed the bug for me > there too. I used the same reproducer that you did. It was easy to reproduce > the > problem with findutils master without the patch, and I could not reproduce > the > problem with the patch applied to findutils/gl/lib/fts*.
ouch, I made a mistake: I forgot that findutils does not link the gnulib files, but instead makes a copy from gnulib/lib/fts.c to gl/lib/fts.c. And I only checked that ./gl/lib/fts.o was removed before the rebuild. A fresh './bootstrap && ./configure && make' fixed it. Sorry. > I'm using Fedora 31 x86-64 on an older machine (circa 2010 CPU) so it's > possible > there's a race that occurs only on a faster machine. But anyway, for me the > patch improves reliably greatly (though as I said I doubt it's a full fix). I'm testing with a loop-mounted XFS file system backed by a 500M file on /dev/shm. I ran both the old and the new find 10000x each in two terminals in parallel, while the script of the OP constantly changed the file system. The older /usr/bin/find (= origin/master at v4.7.0-33-ge6149e40) crashed 2960x, while the newer one with your patch did not crash at all. So from my point of view, your patch fixed the bug. FWIW: both additionally complained 130x (old) resp. 127x (new) about vanished files (although I used the -ignore_readdir_race option), and therefore exited !=0. That readdir race should not happen and is tracked in another ticket in findutils. Thanks & have a nice day, Berny
