Hi Bernhard,
> From: Bernhard Voelker <m...@bernhard-voelker.de, sent: Thursday, January 23,
> 2025 10:49 PM:
>
> Hi Dietmar,
>
> On 1/22/25 15:47, Dietmar Hahn (Fujitsu) via Bug reports for the GNU find
> utilities wrote:
> > Hi list,
> >
> > I have 2 core files from the find command.
> > It's findutils-4.8.0-1.20 from SuSE SLES15SP5.
>
> thanks for the bug report.
>
> > Core was generated by `find -type f -name *xx* -empty -delete'.
>
> Just to be sure that nothing else plays into the game:
>
> Did you pass the file name unquoted?
> -name *xx*
No, the line above is the output when calling gdb with the core file. Sorry for
not being clear.
The call is:
find -type f -name "*xx*" -empty -delete
> I.e., is it sure that find(1) saw '*xx*' as pattern, not any file names the
> shell
> expanded via globbing?
>
> > Program terminated with signal SIGSEGV, Segmentation fault.
> > #0 0x000055a1a5407999 in partial_quotearg_n (n=1,
> style=locale_quoting_style, len=4026533546,
> > s=0x300008000 <error: Cannot access memory at address
> 0x300008000>) at ftsfind.c:202
> >
> > (gdb) bt
> > #0 0x000055a1a5407999 in partial_quotearg_n (n=1,
> style=locale_quoting_style, len=4026533546,
> > s=0x300008000 <error: Cannot access memory at address
> 0x300008000>) at ftsfind.c:202
> > #1 issue_loop_warning (ent=0x55a1a6ee79d0) at ftsfind.c:241
> > #2 consider_visiting (ent=0x55a1a6ee79d0, p=0x55a1a6e84640) at
> ftsfind.c:318
> > #3 find (arg=arg@entry=0x7ffc7dfc8946 ".") at ftsfind.c:539
> > #4 0x000055a1a540704f in process_all_startpoints (argv=<optimized out>,
> argc=<optimized out>) at ftsfind.c:593
> > #5 main (argc=<optimized out>, argv=<optimized out>) at ftsfind.c:689
> > (gdb) up
> > #1 issue_loop_warning (ent=0x55a1a6ee79d0) at ftsfind.c:241
> > 241 in ftsfind.c
> > (gdb) up
> > #2 consider_visiting (ent=0x55a1a6ee79d0, p=0x55a1a6e84640) at
> ftsfind.c:318
> > 318 in ftsfind.c
> >
> > It seems to be in
> > issue_loop_warning (FTSENT * ent)
> > ...
> > error (0, 0,
> > _("File system loop detected; "
> > "%s is part of the same file system loop as %s."),
> > safely_quote_err_filename (0, ent->fts_path),
> > partial_quotearg_n (1,
> > ent->fts_cycle->fts_path,
> > ent->fts_cycle->fts_pathlen,
> > options.err_quoting_style));
> >
> > (gdb) p *ent
> > $1 = {fts_cycle = 0x55a1a6e8d350, fts_parent = 0x55a1a6e8cdb0, fts_link =
> 0x55a1a6ee7ae0, fts_dirp = 0x0,
> > fts_number = 0, fts_pointer = 0x0, fts_accpath = 0x55a1a6ee7ad0 "nfsfs",
> > fts_path = 0x55a1a6e846d0
> "./var/lib/dhcp/proc/56755/task/57302/net/nfsfs", fts_errno = 2, fts_symfd
> = 21921,
> > fts_pathlen = 46, fts_fts = 0x55a1a6e84640, fts_level = 9, fts_namelen =
> > 5,
> fts_info = 2, fts_flags = 0,
> > fts_instr = 3, fts_statp = {{st_dev = 0, st_ino = 0, st_nlink = 0,
> > st_mode = 0,
> st_uid = 0, st_gid = 0, __pad0 = 0,
> > st_rdev = 0, st_size = 0, st_blksize = 0, st_blocks = 0, st_atim =
> > {tv_sec = 0,
> tv_nsec = 0}, st_mtim = {
> > tv_sec = 0, tv_nsec = 0}, st_ctim = {tv_sec = 0, tv_nsec = 0},
> __glibc_reserved = {0, 0, 0}}},
> > fts_name = 0x55a1a6ee7ad0 "nfsfs"}
> >
> > (gdb) p *ent->fts_cycle
> > $2 = {fts_cycle = 0x55a1a6e84640, fts_parent = 0x8, fts_link = 0x7,
> > fts_dirp =
> 0x30000000b,
> > fts_number = 94152778335808, fts_pointer = 0x145dfdf4,
> > fts_accpath = 0xe <error: Cannot access memory at address 0xe>,
> > fts_path = 0x300008000 <error: Cannot access memory at address
> 0x300008000>, fts_errno = 0, fts_symfd = 21921,
> > fts_pathlen = 4026533546, fts_fts = 0x1, fts_level = 32768, fts_namelen =
> 1, fts_info = 6, fts_flags = 0,
> > fts_instr = 3, fts_statp = {{st_dev = 1, st_ino = 341704063, st_nlink =
> > 2,
> st_mode = 16713, st_uid = 0,
> > st_gid = 496, __pad0 = 0, st_rdev = 0, st_size = 0, st_blksize =
> > 1024,
> st_blocks = 28550371716918627, st_atim = {
> > tv_sec = 81, tv_nsec = 139865846925952}, st_mtim = {tv_sec =
> 94152778763600, tv_nsec = 6859885147964993378},
> > st_ctim = {tv_sec = 55424210788214, tv_nsec = 17591801},
> __glibc_reserved = {33, 94152778730496,
> > 139865846925904}}}, fts_name = 0x55a1a6e8d450 "P"}
> >
> > The fts_cycle looks corrupted.
>
> The underlying gnulib code seems to be a bit vague about this,
> and the comment about coreutils is also not true (any more):
> https://git.savannah.gnu.org/cgit/gnulib.git/tree/lib/fts-cycle.c#n110
>
> /* FIXME: setting fts_cycle like this isn't proper.
> To do what the documentation requires, we'd have to
> go around the cycle again and find the right entry.
> But no callers in coreutils use the fts_cycle member. */
> ent->fts_cycle = ent;
> ent->fts_info = FTS_DC;
>
> > Is this a known and maybe fixed problem in a newer version (I couldn't find
> anything) ?
>
> no, new.
Maybe it has something to do with the mounted procfs in dhcp (but with an
special situation):
# mount | grep dhcp
proc on /var/lib/dhcp/proc type proc (ro,relatime)
And as mentioned we didn't use -xdev or -mount.
Sorry that I can't help more.
Dietmar.
> > I don't know what is causing the problem and can not reproduce it. It
> happened once in November and once in January.
> > Btw the find was called in / by mistake.
> > Many thanks in advance.
> > Dietmar.
>
> Have a nice day,
> Berny
