Re: tests: Flaky strace-tst-thp-*-disabled tests

On 19/08/26 08:48, Yury Khrustalev wrote:
> On Wed, Aug 19, 2026 at 08:34:30AM -0300, Adhemerval Zanella Netto wrote:
>>
>> On 19/08/26 05:55, Yury Khrustalev wrote:
>>> Hi everyone,
>>>
>>> Has anyone else noticed that the elf/strace-tst-thp-*-disabled tests are
>>> flaky producing FAIL results because madvise syscall occasionally occurs
>>> despite using tunable glibc.elf.thp=0?
>>>
>>> The current logic of how this tunable is handled is a bit complex, I'm
>>> trying to pin point the reason for this, but I've seen these tests
>>> failing from time to time with no particular pattern.
>> I recalled that I saw some spurious issue after the release, but I haven't
>> see any after 2be733e9e0b2e8871cd282f2ee868d75108db7f1. I will double check.
> 
> I see it on recent master including today's commit a0faa928b0.
> 
>   fails=0; for ((i=0;i<100;i++)); \
>     do make test t=elf/strace-tst-thp-1-disabled |& grep -qw FAIL && ((fails++)); \
>     done; echo "$fails failed"
> 
> I see ~7 failures for 100 test runs.

Ack, I could reproduce it and the strace output for the failures is:

--
execve("/home/adhemerval.zanella/projects-local/glibc/build/aarch64-linux-gnu/elf/tst-thp-1", ["/home/adhemerval.zanella/project"..., "--direct"], 0xffffce54e5d8 /* 45 vars */) = 0
newfstatat(-100, "/etc/ld.so.cache", {st_mode=0100644, st_size=52911, ...}, 0) = 0
openat(-100, "/etc/ld.so.cache", 0x80000) = 3
fstat(3, {st_mode=0100644, st_size=52911, ...}) = 0
mmap(NULL, 52911, 0x1, 0x2, 3, 0)       = 0xe6d6503ba000
close(3)                                = 0
brk(NULL)                               = 0xacbbdf1e6000
mmap(NULL, 8192, 0x3, 0x22, -1, 0)      = 0xe6d65038d000
faccessat(-100, "/etc/ld.so.preload", 0x4) = -1 ENOENT (No such file or directory)
openat(-100, "/home/adhemerval.zanella/projects-local/glibc/build/aarch64-linux-gnu/libc.so.6", 0x80000) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0`r\2\0\0\0\0\0"..., 1024) = 1024
fstat(3, {st_mode=0100775, st_size=11583592, ...}) = 0
mmap(NULL, 2088512, 0, 0x822, -1, 0)    = 0xe6d65018f000
mmap(0xe6d650190000, 2022976, 0x5, 0x812, 3, 0) = 0xe6d650190000
munmap(0xe6d65018f000, 4096)            = 0
munmap(0xe6d65037e000, 60992)           = 0
mprotect(0xe6d650359000, 81920, 0)      = 0
mmap(0xe6d65036d000, 20480, 0x3, 0x812, 3, 0x1cd000) = 0xe6d65036d000
mmap(0xe6d650372000, 48704, 0x3, 0x32, -1, 0) = 0xe6d650372000
close(3)                                = 0
mmap(NULL, 8192, 0x3, 0x22, -1, 0)      = 0xe6d65038b000
set_tid_address(0xe6d65038b848)         = 501182
set_robust_list(0xe6d65038b500, 24)     = 0
rseq(0xe6d65038bc00, 0x21, 0, 0xd428bc00) = 0
getrandom("\xac\xae\x9e\xbf\xde\x2c\x43\x23\xd3\xcd\x37\x49\x67\xc3\xb6\x72", 16, 0x1) = 16
mprotect(0xe6d65036d000, 12288, 0x1)    = 0
mprotect(0xacbbd77ff000, 4096, 0x1)     = 0
mprotect(0xe6d6503cd000, 8192, 0x1)     = 0
prlimit64(0, 0x3, NULL, {rlim_cur=8388608, rlim_max=18446744073709551615}) = 0
getrandom("\x39\x40\x90\xa3\x14\x70\x4e\x47", 8, 0x1) = 8
mmap(NULL, 12, 0x3, 0x21, -1, 0)        = 0xe6d65038a000
openat(-100, "/sys/kernel/mm/transparent_hugepage/hpage_pmd_size", 0) = 3
read(3, "2097152\n", 21)                = 8
close(3)                                = 0
openat(-100, "/sys/kernel/mm/transparent_hugepage/enabled", 0) = 3
read(3, "always [madvise] never\n", 24) = 23
close(3)                                = 0
brk(NULL)                               = 0xacbbdf1e6000
brk(0xacbbdf400000)                     = 0xacbbdf400000
madvise(0xacbbdf1e6000, 2203648, 0xe)   = 0
openat(-100, "/proc/self/maps", 0)      = 3
fstat(3, {st_mode=0100444, st_size=0, ...}) = 0
read(3, "acbbd6c00000-acbbd6c02000 r--p 0"..., 1024) = 1024
read(3, "9000-e6d65036d000 ---p 001c9000 "..., 1024) = 1024
read(3, "        [vdso]\ne6d6503cd000-e6d6"..., 1024) = 451
read(3, "", 1024)                       = 0
close(3)                                = 0
exit_group(0)                           = ?
+++ exited with 0 +++
---

You can see that there is an unexpected 'madvise' at the heap address 0xacbbdf1e6000,
and I think it comes from madvise_thp called from sysmalloc's brk path (malloc.c:2307).

On aarch64 with glibc.elf.thp=0, do_set_hugetlb sets 'mp_.thp_mode = thp_mode_madvise'
and 'mp_.thp_pagesize = 2MB'. And since THP mode is 'madvise' (the openat for
'/sys/kernel/mm/transparent_hugepage/enabled'), the heap extension is called from
the test own malloc. The madvise call will then be dependent of the ASLR placement
of the heap base address, where sysmalloc rounds the brk top up to the 2 MB THP page
size.

I think the cleanest fix would be to add glibc.malloc.hugetlb=0 in all the
strace-tst-thp-* Makefile rules.