Source: golang-1.25
Version: 1.25.6-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Forwarded: https://github.com/golang/go/issues/77289
X-Debbugs-Cc: debian-s390@lists.debian.org, tianon@debian.org
User: debian-s390@lists.debian.org
Usertags: s390x


Go 1.25 FTBFS on s390x on the buildds after my most recent upload.

I don't think this is actually related to the 1.25.6 upload, and I bet
that it would *also* reproduce if 1.25.3 were rebuilt.

I filed a bug with upstream (https://github.com/golang/go/issues/77289),
but I think the root cause is most likely src:gcc-15 version 15.2.0-12,
which includes "Build liblsan and libtsan on s390x." in the changelog:
https://tracker.debian.org/news/1699395/accepted-gcc-15-1520-12-source-all-amd64-into-unstable/

There's a failing build log at
https://buildd.debian.org/status/fetch.php?pkg=golang-1.25&arch=s390x&ver=1.25.6-1&stamp=1769154463&raw=1,
but here's the relevant bit:

--- FAIL: TestTSAN (13.61s)
    --- FAIL: TestTSAN/tsan (0.54s)
        tsan_test.go:99: /usr/bin/setarch s390x -R /tmp/TestTSANtsan1215000322/001/tsan exited with exit status 66
            ThreadSanitizer: CHECK failed: tsan_platform_linux.cpp:571 "((thr_beg)) >= ((tls_addr))" (0x3ffac69e140, 0x3ffac69e240) (tid=50181)
                #0 __tsan::CheckUnwind() ../../../../src/libsanitizer/tsan/tsan_rtl.cpp:676 (libtsan.so.2+0x9020f) (BuildId: f875f192ade23bc40881328d687242f532ffe220)
                #1 __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) ../../../../src/libsanitizer/sanitizer_common/sanitizer_termination.cpp:86 (libtsan.so.2+0xcfbf9) (BuildId: f875f192ade23bc40881328d687242f532ffe220)
                #2 __tsan::ImitateTlsWrite(__tsan::ThreadState*, unsigned long, unsigned long) ../../../../src/libsanitizer/tsan/tsan_platform_linux.cpp:571 (libtsan.so.2+0x8e0c3) (BuildId: f875f192ade23bc40881328d687242f532ffe220)
                #3 __tsan::ThreadStart(__tsan::ThreadState*, unsigned int, unsigned long long, __sanitizer::ThreadType) ../../../../src/libsanitizer/tsan/tsan_rtl_thread.cpp:203 (libtsan.so.2+0xa9035) (BuildId: f875f192ade23bc40881328d687242f532ffe220)
                #4 __tsan_thread_start_func ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:1028 (libtsan.so.2+0x3cb75) (BuildId: f875f192ade23bc40881328d687242f532ffe220)
                #5 <null> <null> (libc.so.6+0xa51a1) (BuildId: 906fc7e75bfa917e7bdb55fef57cec35268ce523)
                #6 <null> <null> (libc.so.6+0x12715f) (BuildId: 906fc7e75bfa917e7bdb55fef57cec35268ce523)

(repeated over and over again, the exact same error/backtrace for
 several TestTSAN/tsanX test runs)


If I don't hear from anyone upstream or on this bug, my plan is to patch
this test out on s390x like we've done for riscv64, but I'd really
rather see a proper fix because this probably is a real bug of some
kind, I just don't know enough about TSAN to say for sure. 😅


♥,
- Tianon

Hi Tianon,

I work in the Toolchain and Compilers team at IBM and has mentioned this
to my colleagues who work on golang for s390x. They will take a look at this.

Thanks,
Pranav

Hi Tianon,

I work in the Toolchain and Compilers team at IBM and has mentioned this
to my colleagues who work on golang for s390x. They will take a look at this.

Thanks,
Pranav

Thanks Pranav, for letting us know of this issue.. We will take a look and update you.. !!

Warm Regards,
Vishwa..

From: Pranav P <pranav.p7@ibm.com>
Date: Saturday, 24 January 2026 at 10:52 PM
To: Debian Bug Tracking System <submit@bugs.debian.org>, Tianon Gravi <tianon@debian.org>, 1126312@bugs.debian.org <1126312@bugs.debian.org>
Cc: Vishwanatha H D <Vishwanatha.HD@ibm.com>
Subject: Re: [EXTERNAL] Bug#1126312: golang-1.25: FTBFS on s390x: TestTSAN: ThreadSanitizer: CHECK failed: tsan_platform_linux.cpp:571

Hi Tianon,

I work in the Toolchain and Compilers team at IBM and has mentioned this
to my colleagues who work on golang for s390x. They will take a look at this.

Thanks,
Pranav

Thanks Pranav, for letting us know of this issue.. We will take a look and update you.. !!

Warm Regards,
Vishwa..

From: Pranav P <pranav.p7@ibm.com>
Date: Saturday, 24 January 2026 at 10:52 PM
To: Debian Bug Tracking System <submit@bugs.debian.org>, Tianon Gravi <tianon@debian.org>, 1126312@bugs.debian.org <1126312@bugs.debian.org>
Cc: Vishwanatha H D <Vishwanatha.HD@ibm.com>
Subject: Re: [EXTERNAL] Bug#1126312: golang-1.25: FTBFS on s390x: TestTSAN: ThreadSanitizer: CHECK failed: tsan_platform_linux.cpp:571

Hi Tianon,

I work in the Toolchain and Compilers team at IBM and has mentioned this
to my colleagues who work on golang for s390x. They will take a look at this.

Thanks,
Pranav

For what it's worth, 1.24 is failing in the same way:
https://buildd.debian.org/status/fetch.php?pkg=golang-1.24&arch=s390x&ver=1.24.12-1&stamp=1769244857&file=log

- Tianon

For what it's worth, 1.24 is failing in the same way:
https://buildd.debian.org/status/fetch.php?pkg=golang-1.24&arch=s390x&ver=1.24.12-1&stamp=1769244857&file=log

- Tianon

Hi Tianon,

I was going through goenv.sh and found out that a
s390x-linux-gnu-g(cc/++) cross compiler is being used for compilation.
We verified the same failure is seen in the upstream repo even on other
distributions when using a cross-compiler. Why is the cross-compiler needed and
not the native compiler enough? Is there a specific need.
Because this failure is not seen with the native compiler (other than for a segfault
seen in tsan8 testcase which we will be working on)
Also, for reference I had checked Ubuntu's packaging. They are also using the native
compiler.

Thanks,
Pranav

Thanks for taking a look!  To clarify, the cross-compiler is *only*
used when cross compiling, which isn't something the official buildds
will ever invoke (and that's where I'm pulling that failure from).

Within Debian, "s390x-linux-gnu-g(cc/++)" is a native compiler when on
the native architecture.

So unless something is going very wrong, the build logs I've provided
should be from the native compiler (with CGO_ENABLED=1 explicitly
enabled).

♥,
- Tianon

Hi Tianon,

Got it. Sorry!
What I intended to say was that this crash is visible only when compiling
using s390x-gnu-linux-g(cc/++) and not when compiling using just `gcc`.
I will try to get better insights and will update you further.

Thanks,
Pranav

Hi Tianon,

The issue we are seeing on golang seems like a bug in ltsan.
I am able to see the same failure in gcc and on further communication
I got to know that this issue has been there since gcc-13. We are still
working on this. I will let you know if I find any updates.

Thanks,
Pranav

Hi Tianon,

I'm wondering if it would be sensible to disable the failing test on
s390 for now -- like you've already said in the github issue. With that
workaround, the golang compiler could migrate to testing, fixing a lot
of CVEs.

What do you think?

Regards,
Tobias

I think that's a great idea; I was planning to do it but life's been in my
way recently, so please do go ahead!

Just so my mental notes are written down here, I was pondering whether it's
worth trying to combine the new patch with the existing riscv64 patch
somehow (an environment variable of arches to skip for tsan tests,
perhaps?) because the patch ordering/interaction is probably going to be
heinous otherwise, but I don't feel strongly about it if you want to do the
work in a different way. 👍

We can technically also exclude tests directly via a (singular combined)
test name regex on the upstream test runner, but that's a whole different
kind of painful, especially if this need grows over time and given the
conditional nature of it.

❤️,
- Tianon

control: severity -1 important

Am 09.02.26 um 18:12 schrieb Tianon Gravi:

Thanks, I've just uploaded golang-1.24 and golang-1.25 with the test
disabled on s390x.

This is not a real fix, of course, just a workaround. Therefore, I
haven't closed this bug in the debian changelog.

However, the FTBFS is resolved, so I'm downgrading the severity to
non-RC, so the migration of the golang-1.25 package to testing is permitted.

When the bug is resolved for real, we can include it in d/changelog and
close it.

Regards,
Tobias

Hi Tianon,

Just a quick update.
We do have a patch for the issue. I will share its link once it is raised in LLVM.

Meanwhile, this is the patch for gcc.

diff --git a/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp b/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp
index 2b4934be0aa..ccc9ed42c5d 100644
--- a/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp
+++ b/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp
@@ -503,10 +503,10 @@ __attribute__((unused)) static void GetStaticTlsBoundary(uptr *addr, uptr *size,
   // loader places static TLS blocks this way not to waste space.
   uptr l = one;
   *align = ranges[l].align;
-  while (l != 0 && ranges[l].begin < ranges[l - 1].end + ranges[l].align)
+  while (l != 0 && ranges[l].begin <= ranges[l - 1].end + ranges[l].align)
     *align = Max(*align, ranges[--l].align);
   uptr r = one + 1;
-  while (r != len && ranges[r].begin < ranges[r - 1].end + ranges[r].align)
+  while (r != len && ranges[r].begin <= ranges[r - 1].end + ranges[r].align)
     *align = Max(*align, ranges[r++].align);
   *addr = ranges[l].begin;
   *size = ranges[r - 1].end - ranges[l].begin;

Thanks,
Pranav

Hi Tianon,

This is the PR link https://github.com/llvm/llvm-project/pull/183106
There hasn't been any response till now.

Thanks,
Pranav