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*
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.
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
