Did this only start recently? The test is quite old.

This wants to allocate a blob larger than half the address space.

(In reply to Sam James from comment #1)
> Did this only start recently? The test is quite old.

Yes.  There were no fails as of March 17, 2026.

Previously, the test was unsupported:

dave@mx3210:~/gnu/glibc/objdir$ cat stdlib/test-bz22786.test-result
UNSUPPORTED: stdlib/test-bz22786
original exit status 77
dave@mx3210:~/gnu/glibc/objdir$ cat stdlib/test-bz22786.out
Repeated allocation (2147483675 bytes): Invalid argument

It was probably due 82d9303976c74c337ef67dda10bf08c2b28aedac, I am not sure if we should just revert or mark XFAIL on hppa. I haven't seen any failure on other 32 bits ABIs, like i386, arm, and powerpc (although I am running on 64 bit kernels).

On 2026-06-15 7:38 a.m., adhemerval.zanella at linaro dot org wrote:
> It was probably due 82d9303976c74c337ef67dda10bf08c2b28aedac, I am not sure if
> we should just revert or mark XFAIL on hppa. I haven't seen any failure on
> other 32 bits ABIs, like i386, arm, and powerpc (although I am running on 64
> bit kernels).

I started bisecting the fail.  You are probably correct that it's due to
82d9303976c74c337ef67dda10bf08c2b28aedac.

This is on a machine with a 64-bit kernel and 8 GB physical memory.  I'm not
sure why the malloc operation fails.  Need to investigate further.

In blob_repeat.c, the mmap call to fill the backing store fails and
a zero'd struct support_blob_repeat is returned from allocate_big.

  /* Fill the backing store.  */
  {
    void *ptr = mmap (target, stride_size, PROT_READ | PROT_WRITE,
                      MAP_FIXED | MAP_FILE | MAP_SHARED, fd, 0);
    if (ptr == MAP_FAILED)
      {
        int saved_errno = errno;
        xmunmap (target, total_size);
        xclose (fd);
        errno = saved_errno;
        return (struct support_blob_repeat) {};
      }

do_test () at test-bz22786.c:45
45        char *path = repeat.start;
(gdb)
47        TEST_VERIFY_EXIT (symlink (".", lnk) == 0);
(gdb) p repeat
$10 = {start = 0x0, size = 0, use_malloc = false}

This causes segv in following mempcpy.

Not sure why this mmap call fails.  In the first mmap call, total_size
is 0x8000001b.  stride_size is 0x400000 in second call.

Helge, do you think this is a kernel mmap bug?

Here is strace output:
[pid  3996] mmap2(NULL, 2147483675, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x78a75000
[pid  3996] getrandom("\xec\xbf\x79\xa3\xf1\x8d\x8e\x4b", 8, GRND_NONBLOCK) = 8
[pid  3996] openat(AT_FDCWD, "/tmp/support_blob_repeat-FwIwK2", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
[pid  3996] unlink("/tmp/support_blob_repeat-FwIwK2") = 0
[pid  3996] fallocate(3, 0, 0, 4194304) = 0
[pid  3996] mmap2(0x78a75000, 4194304, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, 3, 0) = -1 EINVAL (Invalid argument)
[pid  3996] munmap(0x78a75000, 2147483675) = 0
[pid  3996] close(3)                    = 0
[pid  3996] symlink(".", "/tmp/bz22786.FK11i9/symlink") = 0
[pid  3996] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=NULL} ---
[pid  3996] +++ killed by SIGSEGV +++

(In reply to John David Anglin from comment #8)
> Here is strace output:
> [pid  3996] mmap2(NULL, 2147483675, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS,
> -1, 0) = 0x78a75000
> [pid  3996] getrandom("\xec\xbf\x79\xa3\xf1\x8d\x8e\x4b", 8, GRND_NONBLOCK)
> = 8
> [pid  3996] openat(AT_FDCWD, "/tmp/support_blob_repeat-FwIwK2",
> O_RDWR|O_CREAT|O_EXCL, 0600) = 3
> [pid  3996] unlink("/tmp/support_blob_repeat-FwIwK2") = 0
> [pid  3996] fallocate(3, 0, 0, 4194304) = 0
> [pid  3996] mmap2(0x78a75000, 4194304, PROT_READ|PROT_WRITE,
> MAP_SHARED|MAP_FIXED, 3, 0) = -1 EINVAL (Invalid argument)

It looks like hppa is not 

> [pid  3996] munmap(0x78a75000, 2147483675) = 0
> [pid  3996] close(3)                    = 0
> [pid  3996] symlink(".", "/tmp/bz22786.FK11i9/symlink") = 0
> [pid  3996] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR,
> si_addr=NULL} ---
> [pid  3996] +++ killed by SIGSEGV +++

(In reply to John David Anglin from comment #8)
> Here is strace output:
> [pid  3996] mmap2(NULL, 2147483675, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS,
> -1, 0) = 0x78a75000
> [pid  3996] getrandom("\xec\xbf\x79\xa3\xf1\x8d\x8e\x4b", 8, GRND_NONBLOCK)
> = 8
> [pid  3996] openat(AT_FDCWD, "/tmp/support_blob_repeat-FwIwK2",
> O_RDWR|O_CREAT|O_EXCL, 0600) = 3
> [pid  3996] unlink("/tmp/support_blob_repeat-FwIwK2") = 0
> [pid  3996] fallocate(3, 0, 0, 4194304) = 0
> [pid  3996] mmap2(0x78a75000, 4194304, PROT_READ|PROT_WRITE,
> MAP_SHARED|MAP_FIXED, 3, 0) = -1 EINVAL (Invalid argument)
> [pid  3996] munmap(0x78a75000, 2147483675) = 0
> [pid  3996] close(3)                    = 0
> [pid  3996] symlink(".", "/tmp/bz22786.FK11i9/symlink") = 0
> [pid  3996] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR,
> si_addr=NULL} ---
> [pid  3996] +++ killed by SIGSEGV +++


It seems to be a hppa limitation due its virtually-indexed cache:

arch/parisc/kernel/sys_parisc.c:

103 static unsigned long arch_get_unmapped_area_common(struct file *filp,
104         unsigned long addr, unsigned long len, unsigned long pgoff,
105         unsigned long flags, enum mmap_allocation_direction dir)
106 {
[...]
118         do_color_align = 0;
119         if (filp || (flags & MAP_SHARED))
120                 do_color_align = 1;
121         filp_pgoff = GET_FILP_PGOFF(filp);
122
123         if (flags & MAP_FIXED) {
124                 /* Even MAP_FIXED mappings must reside within TASK_SIZE */
125                 if (TASK_SIZE - len < addr)
126                         return -EINVAL;
127
128                 if ((flags & MAP_SHARED) && filp &&
129                     (addr - shared_align_offset(filp_pgoff, pgoff))
130                                 & (SHM_COLOUR - 1))
131                         return -EINVAL;
132                 return addr;
133         }


The 'filp_pgoff' comes from the file's kernel address_space pointer (unknowable and unpredictable from userspace). I think we can harden the allocate_big to:

1. Create and fallocate the backing file first.
2. Fill it via a *non-fixed MAP_SHARED* mapping (mmap (NULL, ...)). The kernel places it at a *correctly-colored* address, which both performs the fill and reveals the color: mapping_colour = addr & (mapping_alignment-1).
3. Reserve the region over-allocated by mapping_alignment, then position its base so target % mapping_alignment == mapping_colour, trimming the head/tail slack.
4. The stride is a multiple of mapping_alignment.

We get a pretty similar fail on ppc32 (powermac g4), see URL...
Also 32bit BE?