consistently hitting gnugrep build failure during gnulib tests coming from nl_langinfo_l (the test validates thread behavior of locale calls):

Exception Type:    EXC_BREAKPOINT (SIGTRAP)
Exception Codes:   0x0000000000000001, 0x00000001821a1154

Termination Reason:  Namespace SIGNAL, Code 5, Trace/BPT trap: 5
Terminating Process: exc handler [81970]


Application Specific Information:
BUG IN CLIENT OF LIBMALLOC: double free detected
Abort Cause 4372392576

Thread 5 Crashed:
0   libsystem_malloc.dylib        	       0x1821a1154 mfm_free.cold.3 + 36
1   libsystem_malloc.dylib        	       0x1821827f0 mfm_free + 1320
2   libsystem_malloc.dylib        	       0x18218d5fc xzm_realloc + 908
3   libsystem_malloc.dylib        	       0x18219a3fc _malloc_zone_realloc + 148
4   libsystem_malloc.dylib        	       0x18219ac2c _realloc + 452
5   libsystem_malloc.dylib        	       0x18219ac84 reallocf + 32
6   libsystem_c.dylib             	       0x18222bde4 nl_langinfo_l + 752
7   test-nl_langinfo-mt           	       0x1040c37e4 thread5_func + 24 (test-nl_langinfo-mt.c:143)
8   libsystem_pthread.dylib       	       0x18236cc08 _pthread_start + 136
9   libsystem_pthread.dylib       	       0x182367ba8 thread_start + 8

This is on a machine that upgraded to 26.0.1. I cannot reproduce the same on another machine that is still on 15.6.1. (community builder which is on 15.7.2 is also fine.)

May I ask someone with 26.x to rebuild it locally from upstream master and see if you by chance can hit the same issue too?

btw what is the version running in Hydra?

commit 8ebd5a9aa7e24dce4ac2fd4f5074b43b00759d54
Author: Bruno Haible <bruno@clisp.org>
Date:   Sat Sep 20 15:49:50 2025 +0200

    nl_langinfo: Work around nl_langinfo multithread-safety bug on macOS 26.

    * m4/nl_langinfo.m4 (gl_FUNC_NL_LANGINFO): Set NL_LANGINFO_MTSAFE to 0
    on macOS.
    * lib/nl_langinfo.c (ITEMS): Define appropriately on macOS.
    * doc/posix-functions/nl_langinfo.texi: Document the macOS bug.

oh my god :(

I see. where has the complaining happened?

I checked the patch - it does some static array of a limited size carrying results over subsequent calls. looks like an actual fix.

# if !NL_LANGINFO_MTSAFE /* macOS, Solaris */

#  ifdef __sun /* Solaris */
#   define ITEMS (MAXSTRMSG + 1)
#  else /* macOS */
#   define ITEMS (CRNCYSTR + 20)
#  endif
#  define MAX_RESULT_LEN 80

static char *
nl_langinfo_unlocked (nl_item item)
{
  static char result[ITEMS][MAX_RESULT_LEN];

  /* The result of nl_langinfo is in storage that can be overwritten by
     other calls to nl_langinfo.  */
  char *tmp = nl_langinfo (item);
  if (item >= 0 && item < ITEMS && tmp != NULL)

No. I ran into it trying to get Lix to use a fixed curl in my configs. I ended up doing this lovely override:

lixPackageSets.stable = nixpkgs-unstable.lixPackageSets.stable.overrideScope (final: prev: {
    lix = prev.lix.override {
      curl = nixpkgs-unstable.curl.override {
        c-aresMinimal = inputs.lix-fixed.legacyPackages.${pkgs.system}.c-aresMinimal.override {
          inherit (nixpkgs-unstable) cmake stdenv updateAutotoolsGnuConfigScriptsHook;
        };
      };
    };
  });

No. I ran into it trying to get Lix to use a fixed curl in my configs. I ended up doing this lovely override:

lixPackageSets.stable = nixpkgs-unstable.lixPackageSets.stable.overrideScope (final: prev: {
  lix = prev.lix.override {
    curl = nixpkgs-unstable.curl.override {
      c-aresMinimal = inputs.lix-fixed.legacyPackages.${pkgs.system}.c-aresMinimal.override {
        inherit (nixpkgs-unstable) cmake stdenv updateAutotoolsGnuConfigScriptsHook;
      };
    };
  };
});