Re: [REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere

From: Dmitry Vyukov

Date: Tue Apr 28 2026 - 07:21:54 EST


On Tue, 28 Apr 2026 at 10:18, Thomas Gleixner <tglx@xxxxxxxxxx> wrote:
>
> On Tue, Apr 28 2026 at 10:07, Thomas Gleixner wrote:
> >> Not sure if that's it, or there is something else.
> >
> > Can you try the updated version below?
>
> Is there a pre-compiled version of those tcmalloc tests somewhere?
>
> I tried to build it from source, but I really have better things to do
> than wasting my time on debugging this bazel nonsense.

I feel your pain.

I've attached an archive with 2 tests that I used.

I've managed to build them using:

USE_BAZEL_VERSION=8.6.0 bazelisk build --repo_env=CC=clang
--repo_env=CXX=clang++ --dynamic_mode=off --fission=no --strip=never
--copt=-gmlt //tcmalloc/internal:percpu_tcmalloc_test
//tcmalloc/testing:background_test_no_glibc_rseq

on tcmalloc commit 8e98046ec5639bffbe70a53770a2699dd355b26d

I unfortunately did not manage to build fully static binaries, so
these still depend on a relatively recent libc. I had to build a
Debian Forky image for qemu to run these binaries...

I also used the stress utility to run these because they crash
non-deterministically:
https://pkg.go.dev/golang.org/x/tools/cmd/stress
It allows to run a binary in parallel loop, looking for different
failure modes and collecting logs.

Hopefully this should work:

$ go install golang.org/x/tools/cmd/stress@latest
$ GLIBC_TUNABLES=glibc.pthread.rseq=0 $HOME/go/bin/stress ./percpu_tcmalloc_test

But otherwise you can try just:

$ GLIBC_TUNABLES=glibc.pthread.rseq=0 ./percpu_tcmalloc_test

Attachment: tcmalloc.tar.gz
Description: application/gzip