Re: Apple LLVM 10 and `__fallthrough__`

[Jeffrey Walton]

On Sun, Feb 26, 2023 at 10:08 PM Alexei Podtelezhnikov
 wrote:
>
> On Sun, Feb 26, 2023 at 7:08 PM Bruno Haible  wrote:
> >
> > Alexei Podtelezhnikov wrote:
> > > -# elif (__GNUC__ >= 7) || (__clang_major__ >= 10)
> > > +# elif ((__GNUC__ >= 7) \
> > > +|| (defined __apple_build_version__ \
> > > +? __apple_build_version__ >= 1400 \
> > > +: __clang_major__ >= 10))
> > >
> > > Wiki suggests __apple_build_version__ >= 1200
> > > https://en.wikipedia.org/wiki/Xcode#Xcode_11.0_-_14.x_(since_SwiftUI_framework)_2
> >
> > Interesting. Can you test it (by compiling Werner's test program from
> > 
> > on an Xcode version between 12.0 and 12.4)?
>
> I wish I could directly test it. However, I could confirm that Swift
> release 5.3 (Xcode 12) was the first release with this line
> https://github.com/apple/llvm-project/blob/swift-5.3-RELEASE/clang/test/Sema/fallthrough-attr.c#L18

Why jump through the compiler version hoops for a non-portable solution?

The simplest solution is to use a /* fallthrough */ comment:
https://stackoverflow.com/a/45137452 . It does not depend on compiler
extensions or language versions.

Jeff

Re: Apple LLVM 10 and `__fallthrough__`

[Alexei Podtelezhnikov]

On Sun, Feb 26, 2023 at 7:08 PM Bruno Haible  wrote:
>
> Alexei Podtelezhnikov wrote:
> > -# elif (__GNUC__ >= 7) || (__clang_major__ >= 10)
> > +# elif ((__GNUC__ >= 7) \
> > +|| (defined __apple_build_version__ \
> > +? __apple_build_version__ >= 1400 \
> > +: __clang_major__ >= 10))
> >
> > Wiki suggests __apple_build_version__ >= 1200
> > https://en.wikipedia.org/wiki/Xcode#Xcode_11.0_-_14.x_(since_SwiftUI_framework)_2
>
> Interesting. Can you test it (by compiling Werner's test program from
> 
> on an Xcode version between 12.0 and 12.4)?

I wish I could directly test it. However, I could confirm that Swift
release 5.3 (Xcode 12) was the first release with this line
https://github.com/apple/llvm-project/blob/swift-5.3-RELEASE/clang/test/Sema/fallthrough-attr.c#L18

Re: Apple LLVM 10 and `__fallthrough__`

[Jeffrey Walton]

On Sun, Feb 26, 2023 at 6:36 PM Alexei Podtelezhnikov
 wrote:
> [...]
> Would  it perhaps be better if clang used [[fallthrough]]  instead of
> __attribute__((fallthrough))? They have supported [[fallthrough]]
> since at least 3.5.0 circa 2014. In this particular case they are
> ahead of GCC and towards the standard acceptance.
> https://releases.llvm.org/3.5.0/tools/clang/docs/AttributeReference.html

I think the best course of action is to use a C comment. GCC and Clang
recognize them, and it does not require compiler extensions or new C
language features:

switch (n)
{
case 1:
n--;
/* fallthrough */
case 0:
/* do something */
break;
default:
/* do something else */
}

Jeff

Re: Apple LLVM 10 and `__fallthrough__`

[Bruno Haible]

Alexei Podtelezhnikov wrote:
> -# elif (__GNUC__ >= 7) || (__clang_major__ >= 10)
> +# elif ((__GNUC__ >= 7) \
> +|| (defined __apple_build_version__ \
> +? __apple_build_version__ >= 1400 \
> +: __clang_major__ >= 10))
> 
> Wiki suggests __apple_build_version__ >= 1200
> https://en.wikipedia.org/wiki/Xcode#Xcode_11.0_-_14.x_(since_SwiftUI_framework)_2

Interesting. Can you test it (by compiling Werner's test program from

on an Xcode version between 12.0 and 12.4)?

> Would  it perhaps be better if clang used [[fallthrough]]  instead of
> __attribute__((fallthrough))? They have supported [[fallthrough]]
> since at least 3.5.0 circa 2014.

They have supported it only in C++ mode. Not in C mode. E.g. with clang 4.0.0:

$ clang -S foo.c
foo.c:9:9: error: expected expression
[[fallthrough]];
^
foo.c:12:9: error: expected expression
[[fallthrough]];
^
2 errors generated.

> There was also a suggestion on this list to use __has_attribute.
> https://lists.gnu.org/archive/html/bug-gnulib/2021-01/msg00267.html

We do so in gnulib-common.m4, and the resulting code is more convoluted
than the code we have now.

Also, we're not using '#include "attribute.h"' in dfa.c because gawk uses
dfa.c and does not like to import so many Gnulib definitions.

Bruno

Re: Apple LLVM 10 and `__fallthrough__`

[Alexei Podtelezhnikov]

-# elif (__GNUC__ >= 7) || (__clang_major__ >= 10)
+# elif ((__GNUC__ >= 7) \
+|| (defined __apple_build_version__ \
+? __apple_build_version__ >= 1400 \
+: __clang_major__ >= 10))

Wiki suggests __apple_build_version__ >= 1200
https://en.wikipedia.org/wiki/Xcode#Xcode_11.0_-_14.x_(since_SwiftUI_framework)_2

Would  it perhaps be better if clang used [[fallthrough]]  instead of
__attribute__((fallthrough))? They have supported [[fallthrough]]
since at least 3.5.0 circa 2014. In this particular case they are
ahead of GCC and towards the standard acceptance.
https://releases.llvm.org/3.5.0/tools/clang/docs/AttributeReference.html

There was also a suggestion on this list to use __has_attribute.
https://lists.gnu.org/archive/html/bug-gnulib/2021-01/msg00267.html

Re: Take account of splitting option in gendocs.sh

[Bruno Haible]

Gavin Smith wrote:
> I notice that this script also still supports texi2html, which is no
> longer developed.  I could produce a patch to remove this support if
> it was very likely that nobody was relying on it.

A web search on www.gnu.org shows that the manuals of at least the following
packages still were generated using texi2html:
  anubis, auctex, autogen, cfengine, cflow, classpath, combine, complexity,
  cpio, freeimpi, freetalk, gama, gnats, gnu-pw-mgr, gnugo, gnuit, gnupod,
  hurd, indent, libcdio, libjit, oleo, plotutils, radius, sqltutor, tar.

That's definitely more than nobody.

Bruno

Take account of splitting option in gendocs.sh

[Gavin Smith]

The patch at the bottom of this mail makes gendocs.sh take account
of the --split option.  Texinfo uses this as one of its manuals
(texi2any_internals) uses --split=chapter for the HTML output.  Up to
this point we have been getting around this problem by using a custom
gendocs template.

It appears that the existing gendocs template was written to support
different splitting possibilities but that gendocs.sh didn't use this
fully.

Please let me know if any further work needs to be done on this patch.

I notice that this script also still supports texi2html, which is no
longer developed.  I could produce a patch to remove this support if
it was very likely that nobody was relying on it.

diff --git a/ChangeLog b/ChangeLog
index 9477335e75..d67b9b2f0a 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2023-02-26  Gavin Smith 
+
+   gendocs: support chapter- and section-level split
+   * build-aux/gendocs.sh:
+   Strip out parts of the template depending on --split.
+   * doc/gendocs_template: Add lines to mark parts of file to output
+   only when splitting HTML by node.
+
 2023-02-26  Bruno Haible  
 
dfa: Avoid warnings with some Apple clang versions.
diff --git a/build-aux/gendocs.sh b/build-aux/gendocs.sh
index 1ad5cf4f5d..ca813bffe3 100755
--- a/build-aux/gendocs.sh
+++ b/build-aux/gendocs.sh
@@ -465,12 +465,20 @@ fi
 
 # 
 printf "\nMaking index.html for %s...\n" "$PACKAGE"
-if test -z "$use_texi2html"; then
-  CONDS="/%%IF  *HTML_SECTION%%/,/%%ENDIF  *HTML_SECTION%%/d;\
- /%%IF  *HTML_CHAPTER%%/,/%%ENDIF  *HTML_CHAPTER%%/d"
+if test x$split = xnode; then
+  CONDS="/%%IF  *HTML_NODE%%/d;/%%ENDIF  *HTML_NODE%%/d;\
+ /%%IF  *HTML_CHAPTER%%/,/%%ENDIF  *HTML_CHAPTER%%/d;\
+ /%%IF  *HTML_SECTION%%/,/%%ENDIF  *HTML_SECTION%%/d;"
+elif test x$split = xchapter; then
+  CONDS="/%%IF  *HTML_CHAPTER%%/d;/%%ENDIF  *HTML_CHAPTER%%/d;\
+ /%%IF  *HTML_SECTION%%/,/%%ENDIF  *HTML_SECTION%%/d;\
+ /%%IF  *HTML_NODE%%/,/%%ENDIF  *HTML_NODE%%/d;"
+elif test x$split = xsection; then
+  CONDS="/%%IF  *HTML_SECTION%%/d;/%%ENDIF  *HTML_SECTION%%/d;\
+ /%%IF  *HTML_CHAPTER%%/,/%%ENDIF  *HTML_CHAPTER%%/d;\
+ /%%IF  *HTML_NODE%%/,/%%ENDIF  *HTML_NODE%%/d;"
 else
-  # should take account of --split here.
-  CONDS="/%%ENDIF.*%%/d;/%%IF  *HTML_SECTION%%/d;/%%IF  *HTML_CHAPTER%%/d"
+  CONDS="/%%IF.*%%/d;/%%ENDIF.*%%/d;" # invalid split argument
 fi
 
 curdate=`$SETLANG date '+%B %d, %Y'`
diff --git a/doc/gendocs_template b/doc/gendocs_template
index a101977dfc..0b959f0379 100644
--- a/doc/gendocs_template
+++ b/doc/gendocs_template
@@ -22,8 +22,10 @@ without any warranty.
 
 HTML
 (%%HTML_MONO_SIZE%%K bytes) - entirely on one web page.
+%%IF HTML_NODE%%
 HTML - with one web page per
 node.
+%%ENDIF HTML_NODE%%
 %%IF HTML_SECTION%%
 HTML - with one web page per
 section.
@@ -35,9 +37,11 @@ without any warranty.
 HTML compressed
 (%%HTML_MONO_GZ_SIZE%%K gzipped characters) - entirely on
 one web page.
+%%IF HTML_NODE%%
 HTML compressed
 (%%HTML_NODE_TGZ_SIZE%%K gzipped tar file) -
 with one web page per node.
+%%ENDIF HTML_NODE%%
 %%IF HTML_SECTION%%
 HTML compressed
 (%%HTML_SECTION_TGZ_SIZE%%K gzipped tar file) -

Re: Updating in glibc and gnulib

[Bruno Haible]

Florian Weimer wrote:
> Does gnulib still override  unconditionally?

Gnulib does not override , and never did.

That is, when a package that uses Gnulib does
  #include 
it will get the  of the system (from glibc, *BSD, Cygwin,
etc.).

Only when a package uses the compiler option "-I /usr/include/sys"
and
  #include 
there would be a conflict between what Gnulib ships and the installed
file in /usr/include/sys. But nobody does that, because there would
already be a conflict between  and .

What Gnulib does is to ship a copy of glibc's  as ,
not . And it is used for a few compilation units only
(essentially regex, fnmatch, glob, and a few others).

> Why does gnulib bundle ?

Gnulib takes the source code of regex, fnmatch, glob, and a few other
functions from glibc and makes them portable to other platforms. Since
this source code contains references to __glibc_unlikely,
__attribute_warn_unused_result__, etc., Gnulib uses the copy of cdefs.h
to define these macros in the way the source code shared with glibc
expects it.

Some of these symbols are also defined on other platforms, sometimes
differently. Therefore Gnulib has to be careful to not override essential
symbols of these other platforms. It's not trivial, but there appears
to be enough room to navigate through the two constraints. [1]

> In the past, some gnulib-using programs supplied their own copy
> of  instead, even when building against glibc.  This caused
> build failures in the glibc headers because they (quite reasonably)
> assumed that  defines the macros for that glibc version.

You need to take this up with the respective packages. As I said above,
Gnulib overrides , not .

There were some problems around the 'glob' code, but they were resolved
more than 1.5 years ago. This area is still a bit fragile, though.

> We could move glibc's internal definitions to a new header, reducing
>  in scope, but presumably that means gnulib would just
> starting bundling that other header, and we would have the same issue
> once more.

Yes, such a move would be pointless.

Bruno

[1] https://lists.gnu.org/archive/html/bug-gnulib/2023-01/msg00238.html

Re: Apple LLVM 10 and `__fallthrough__`

[Werner LEMBERG]

> I haven't been able to find out precisely which versions produce the
> warning, by looking at https://github.com/apple/llvm-project . So,
> I'm applying the conservative patch: [...]

Thanks!  Maybe other Apple users chime in so that the test can be
refined if necessary.


Werner

Re: FYI: announce-gen: add more info to the auto-generated announce template

[Jim Meyering]

On Sat, Feb 25, 2023 at 11:56 PM Bruno Haible  wrote:
> Jim Meyering wrote:
> > from coreutils-9.2 or openBSD's cksum since 2007.
>
> It's the first time I see OpenBSD spelled this way. Why not use an
> uppercase 'O', like they do themselves [1] ?

Thanks. Corrected.

Re: Cannot build fstat.c on mingw

[Bruno Haible]

Reuben Thomas wrote:
> I get an error with compiling:
> 
> In file included from fstat.c:52:
> stat-time.h: In function ‘get_stat_atime_ns’:
> stat-time.h:52:43: error: invalid use of undefined type ‘const struct
> _stati64’
>52 | #  define STAT_TIMESPEC(st, st_xtim) ((st)->st_xtim)
> 
> and lots more the same.
> 
> I came across this when trying to build GNU libiconv 1.17, which seems to
> use the current version of fstat.c.

GNU libiconv 1.17 compiles fine for mingw (w64 flavour, as shipped with
Cygwin 2.9.0), for me.

So, the cause could be that you are using a different version of mingw.
You might not be the only one. Therefore it would be useful if you could
analyze this failure. Then, let's see what is the best way forward (in
Gnulib and in libiconv).

Thanks!

Bruno

Support FALLTHROUGH macro better in glibc+clang

[Bruno Haible]

Looking through the FALLTHROUGH definitions in gnulib, it appears that it
has the assumption built-in that glibc will only be built by GCC.

Nowadays people are alternatively using (non-Apple) clang to build glibc, see
https://www.collabora.com/news-and-blog/blog/2021/09/30/a-tale-of-two-toolchains-and-glibc/
https://www.collabora.com/news-and-blog/blog/2023/01/17/a-brave-new-world-building-glibc-with-llvm/

To help going in this direction, how about this patch? Paul, do you object?


2023-02-26  Bruno Haible  

Support FALLTHROUGH macro better in glibc+clang.
* lib/fnmatch.c (FALLTHROUGH): Use __attribute__ ((__fallthrough__))
also in clang >= 10.
* lib/fts.c (FALLTHROUGH): Likewise.
* lib/regex_internal.h (FALLTHROUGH): Likewise.

diff --git a/lib/fnmatch.c b/lib/fnmatch.c
index 7c9c4e0f24..306b967c62 100644
--- a/lib/fnmatch.c
+++ b/lib/fnmatch.c
@@ -64,7 +64,7 @@ extern int fnmatch (const char *pattern, const char *string, 
int flags);
 #endif
 
 #ifdef _LIBC
-# if __GNUC__ >= 7
+# if (__GNUC__ >= 7) || (__clang_major__ >= 10)
 #  define FALLTHROUGH __attribute__ ((__fallthrough__))
 # else
 #  define FALLTHROUGH ((void) 0)
diff --git a/lib/fts.c b/lib/fts.c
index 78584b2902..388d251252 100644
--- a/lib/fts.c
+++ b/lib/fts.c
@@ -203,7 +203,7 @@ enum Fts_stat
 #endif
 
 #ifdef _LIBC
-# if __GNUC__ >= 7
+# if (__GNUC__ >= 7) || (__clang_major__ >= 10)
 #  define FALLTHROUGH __attribute__ ((__fallthrough__))
 # else
 #  define FALLTHROUGH ((void) 0)
diff --git a/lib/regex_internal.h b/lib/regex_internal.h
index 149ec2e868..d4dae98534 100644
--- a/lib/regex_internal.h
+++ b/lib/regex_internal.h
@@ -822,7 +822,7 @@ re_string_elem_size_at (const re_string_t *pstr, Idx idx)
 }
 
 #ifdef _LIBC
-# if __GNUC__ >= 7
+# if (__GNUC__ >= 7) || (__clang_major__ >= 10)
 #  define FALLTHROUGH __attribute__ ((__fallthrough__))
 # else
 #  define FALLTHROUGH ((void) 0)

Cannot build fstat.c on mingw

[Reuben Thomas]

I get an error with compiling:

In file included from fstat.c:52:
stat-time.h: In function ‘get_stat_atime_ns’:
stat-time.h:52:43: error: invalid use of undefined type ‘const struct
_stati64’
   52 | #  define STAT_TIMESPEC(st, st_xtim) ((st)->st_xtim)

and lots more the same.

I came across this when trying to build GNU libiconv 1.17, which seems to
use the current version of fstat.c.

-- 
https://rrt.sc3d.org

Re: Apple LLVM 10 and `__fallthrough__`

[Bruno Haible]

Hi Werner,

> In `lib/dfa.c` I see
> 
> ```
> ...
> # elif (__GNUC__ >= 7) || (__clang_major__ >= 10)
> #  define FALLTHROUGH __attribute__ ((__fallthrough__))
> ...
> ```
> 
> I now wonder whether it would be better to have a special case for
> Apple LLVM to avoid this warning.

Indeed, it's not the first time that we see that the Apple
compiler with a certain LLVM version behaves differently (more
like an older compiler) than the original LLVM compiler with that
version. One can use __apple_build_version__ or __APPLE_CC__ to detect
this situation.

> ```
> #include
> 
> int main(int argc, char* argv[])
> {
> switch(argc)
> {
> case 3:
> puts(argv[2]);
> __attribute__((fallthrough));
> case 2:
> puts(argv[1]);
> __attribute__((__fallthrough__));
> case 1:
> puts(argv[0]);
> /* fall through */
> default:
> puts("done");
> }
> }
> ```
> 
> if compiled with
> 
> ```
> $ llvm-gcc --version
> Apple LLVM version 10.0.0 (clang-1000.10.44.4)
> Target: x86_64-apple-darwin17.7.0
> Thread model: posix
> InstalledDir: /Library/Developer/CommandLineTools/usr/bin
> ```
> 
> yields
> 
> ```
> nicola@Quark:freetype $ clang main.c
> main.c:9:9: warning: declaration does not declare anything 
> [-Wmissing-declarations]
> __attribute__((fallthrough));
> ^
> main.c:12:9: warning: declaration does not declare anything 
> [-Wmissing-declarations]
> __attribute__((__fallthrough__));
> ^
> 2 warnings generated.
> ```

On the other hand, the same file, compiled by

  Apple clang version 14.0.0 (clang-1400.0.29.202)
  Target: arm64-apple-darwin21.6.0
  Thread model: posix
  InstalledDir: /Library/Developer/CommandLineTools/usr/bin

produces no warnings.

I haven't been able to find out precisely which versions produce the warning,
by looking at https://github.com/apple/llvm-project . So, I'm applying the
conservative patch:


2023-02-26  Bruno Haible  

dfa: Avoid warnings with some Apple clang versions.
Reported by Werner Lemberg  in
.
* lib/dfa.c (FALLTHROUGH): When __apple_build_version__ is defined,
ignore __clang_major__.

diff --git a/lib/dfa.c b/lib/dfa.c
index 211e1ed18f..994900fea2 100644
--- a/lib/dfa.c
+++ b/lib/dfa.c
@@ -67,7 +67,10 @@ c_isdigit (char c)
 #ifndef FALLTHROUGH
 # if 201710L < __STDC_VERSION__
 #  define FALLTHROUGH [[__fallthrough__]]
-# elif (__GNUC__ >= 7) || (__clang_major__ >= 10)
+# elif ((__GNUC__ >= 7) \
+|| (defined __apple_build_version__ \
+? __apple_build_version__ >= 1400 \
+: __clang_major__ >= 10))
 #  define FALLTHROUGH __attribute__ ((__fallthrough__))
 # else
 #  define FALLTHROUGH ((void) 0)

Re: lib/fts.c: return when malloc failed

[Pádraig Brady]

On 26/02/2023 14:46, ChuanGang Jiang wrote:

Hi，‘rm’ of coreutils was terminated with signal SIGSEGV, Segmentation fault.
Here is the backtrace with gdb.

Core was generated by `/usr/bin/rm -rf test1/test2/'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  cycle_check (state=0x0, sb=sb@entry=0x56296ac29e00) at 
../lib/cycle-check.c:60
60assure (state->magic == CC_MAGIC);
(gdb) bt full
#0  cycle_check (state=0x0, sb=sb@entry=0x56296ac29e00) at 
../lib/cycle-check.c:60
 __PRETTY_FUNCTION__ = "cycle_check"
#1  0x56296aa3d8bd in enter_dir (fts=0x56296ac28ae0, ent=0x56296ac29d90) at 
../lib/fts-cycle.c:108
 st = 
 ad = 
 ad_from_table = 
#2  0x56296aa3f031 in rpl_fts_read (sp=sp@entry=0x56296ac28ae0) at 
../lib/fts.c:1024
 p = 0x56296ac29d90
 tmp = 
 instr = 
 t = 
#3  0x56296aa39858 in rm (file=, x=0x7ffc10c71c60) at 
../src/remove.c:597
 ent = 
 s = 
 bit_flags = 
 fts = 0x56296ac28ae0
 rm_status = RM_OK
 __PRETTY_FUNCTION__ = "rm"
#4  0x56296aa388e2 in main (argc=, argv=0x7ffc10c71e88) at 
../src/rm.c:370
 preserve_root = true
 x = {ignore_missing_files = true, interactive = RMI_NEVER, one_file_system = 
false, recursive = true, remove_empty_directories = false, root_dev_ino = 
0x56296aa480b0 , preserve_all_root = false,
   stdin_tty = true, verbose = false, require_restore_cwd = false}
 prompt_once = 
 c = 
 n_files = 
 file = 0x7ffc10c71e98
 status = 
 __PRETTY_FUNCTION__ = "main"


I think it should return when malloc failed for ’fts->fts_cycle.state‘ in 
’setup_dir(sp)‘
and the patch below may fix this.


*lib/fts.c：return when malloc failed in function setup_dir()
---
  lib/fts.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/lib/fts.c b/lib/fts.c
index 78584b2902..374efa1be7 100644
--- a/lib/fts.c
+++ b/lib/fts.c
@@ -979,7 +979,10 @@ next:   tmp = p;
  }
  free_dir(sp);
  fts_load(sp, p);
-setup_dir(sp);
+if (! setup_dir(sp)) {
+free_dir(sp);
+return (NULL);
+}
  goto check_for_dir;
  }



I agree that assertion may trigger if setup_dir() fails.
free_dir() is safe to call upon setup_dir() failure,
so the patch looks correct.
The only way that setup_dir() can really fail is due to no memory,
so I'd also __set_errno (ENOMEM); in this case.

How did you notice this?
Did you apply artificial mem pressure for testing?

thanks!
Pádraig

lib/fts.c: return when malloc failed

[ChuanGang Jiang]

Hi，‘rm’ of coreutils was terminated with signal SIGSEGV, Segmentation fault.
Here is the backtrace with gdb.

Core was generated by `/usr/bin/rm -rf test1/test2/'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  cycle_check (state=0x0, sb=sb@entry=0x56296ac29e00) at 
../lib/cycle-check.c:60
60assure (state->magic == CC_MAGIC);
(gdb) bt full
#0  cycle_check (state=0x0, sb=sb@entry=0x56296ac29e00) at 
../lib/cycle-check.c:60
__PRETTY_FUNCTION__ = "cycle_check"
#1  0x56296aa3d8bd in enter_dir (fts=0x56296ac28ae0, ent=0x56296ac29d90) at 
../lib/fts-cycle.c:108
st = 
ad = 
ad_from_table = 
#2  0x56296aa3f031 in rpl_fts_read (sp=sp@entry=0x56296ac28ae0) at 
../lib/fts.c:1024
p = 0x56296ac29d90
tmp = 
instr = 
t = 
#3  0x56296aa39858 in rm (file=, x=0x7ffc10c71c60) at 
../src/remove.c:597
ent = 
s = 
bit_flags = 
fts = 0x56296ac28ae0
rm_status = RM_OK
__PRETTY_FUNCTION__ = "rm"
#4  0x56296aa388e2 in main (argc=, argv=0x7ffc10c71e88) at 
../src/rm.c:370
preserve_root = true
x = {ignore_missing_files = true, interactive = RMI_NEVER, 
one_file_system = false, recursive = true, remove_empty_directories = false, 
root_dev_ino = 0x56296aa480b0 , preserve_all_root = false,
  stdin_tty = true, verbose = false, require_restore_cwd = false}
prompt_once = 
c = 
n_files = 
file = 0x7ffc10c71e98
status = 
__PRETTY_FUNCTION__ = "main"


I think it should return when malloc failed for ’fts->fts_cycle.state‘ in 
’setup_dir(sp)‘  
and the patch below may fix this.


*lib/fts.c：return when malloc failed in function setup_dir()
---
 lib/fts.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/lib/fts.c b/lib/fts.c
index 78584b2902..374efa1be7 100644
--- a/lib/fts.c
+++ b/lib/fts.c
@@ -979,7 +979,10 @@ next:   tmp = p;
 }
 free_dir(sp);
 fts_load(sp, p);
-setup_dir(sp);
+if (! setup_dir(sp)) {
+free_dir(sp);
+return (NULL);
+}
 goto check_for_dir;
 }

--
2.36.1


Best Regards
ChuanGang Jiang