Re: find command trigger coredump

[Bernhard Voelker]

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