RE: find terminated with SIGSEGV in partial_quotearg_n

Hi Bernhard,

> From: Bernhard Voelker <[email protected], 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