On Tue, 26 Aug 2025 at 20:09, Bo YU <[email protected]> wrote: > Now golang-1.24 has one FTBFS on riscv64 due to: > > ``` > --- FAIL: TestShared (0.00s) > cshared_test.go:61: skipping msan_shared test on linux/riscv64; -msan > option is not supported. > --- FAIL: TestShared/tsan_shared (121.78s) > cshared_test.go:112: /usr/bin/setarch riscv64 -R > /tmp/TestSharedtsan_shared3507443847/001/tsan_shared exited with exit status > 66 > FATAL: ThreadSanitizer: memory layout is incompatible, even > though ASLR is disabled. > Please file a bug. > ==63940==Process memory map follows: > 0x002aaaaaa000-0x002aaaaab000 > /tmp/TestSharedtsan_shared3507443847/001/tsan_shared > 0x002aaaaab000-0x002aaaaac000 > /tmp/TestSharedtsan_shared3507443847/001/tsan_shared > 0x002aaaaac000-0x002aaaaad000 > /tmp/TestSharedtsan_shared3507443847/001/tsan_shared > 0x003fe6c51000-0x003fe6c66000 > 0x003fe6c66000-0x003fe6c82000 > /usr/lib/riscv64-linux-gnu/libgcc_s.so.1 > 0x003fe6c82000-0x003fe6c83000 > /usr/lib/riscv64-linux-gnu/libgcc_s.so.1 > 0x003fe6c83000-0x003fe6c84000 > /usr/lib/riscv64-linux-gnu/libgcc_s.so.1 > 0x003fe6c84000-0x003fe6d07000 > /usr/lib/riscv64-linux-gnu/libm.so.6 > 0x003fe6d07000-0x003fe6d08000 > /usr/lib/riscv64-linux-gnu/libm.so.6 > 0x003fe6d08000-0x003fe6d09000 > /usr/lib/riscv64-linux-gnu/libm.so.6 > 0x003fe6d09000-0x003fe6e5e000 > /usr/lib/riscv64-linux-gnu/libc.so.6 > 0x003fe6e5e000-0x003fe6e61000 > /usr/lib/riscv64-linux-gnu/libc.so.6 > 0x003fe6e61000-0x003fe6e63000 > /usr/lib/riscv64-linux-gnu/libc.so.6 > 0x003fe6e63000-0x003fe6e6f000 > 0x003fe6e6f000-0x003fe6f09000 > /tmp/TestSharedtsan_shared3507443847/001/libtsan_shared.so > 0x003fe6f09000-0x003fe6f6f000 > /tmp/TestSharedtsan_shared3507443847/001/libtsan_shared.so > 0x003fe6f6f000-0x003fe6f74000 > /tmp/TestSharedtsan_shared3507443847/001/libtsan_shared.so > 0x003fe6f74000-0x003fe6f97000 > 0x003fe6f97000-0x003fe70b9000 > /usr/lib/riscv64-linux-gnu/libtsan.so.2.0.0 > 0x003fe70b9000-0x003fe70be000 > /usr/lib/riscv64-linux-gnu/libtsan.so.2.0.0 > 0x003fe70be000-0x003fe70c6000 > /usr/lib/riscv64-linux-gnu/libtsan.so.2.0.0 > 0x003fe70c6000-0x003ff7fd6000 > 0x003ff7fd6000-0x003ff7fd9000 > 0x003ff7fd9000-0x003ff7fdb000 [vvar] > 0x003ff7fdb000-0x003ff7fdc000 [vdso] > 0x003ff7fdc000-0x003ff7ffc000 > /usr/lib/riscv64-linux-gnu/ld-linux-riscv64-lp64d.so.1 > 0x003ff7ffc000-0x003ff7ffe000 > /usr/lib/riscv64-linux-gnu/ld-linux-riscv64-lp64d.so.1 > 0x003ff7ffe000-0x003ff7fff000 > /usr/lib/riscv64-linux-gnu/ld-linux-riscv64-lp64d.so.1 > 0x003ff7fff000-0x003ff8000000 > 0x003ffffde000-0x004000000000 [stack] > ==63940==End of process memory map. > --- FAIL: TestTSAN (173.01s) > --- FAIL: TestTSAN/tsan (35.03s) > tsan_test.go:95: /usr/bin/setarch riscv64 -R > /tmp/TestTSANtsan1239464039/001/tsan exited with exit status 66 > ``` > > see: > https://buildd.debian.org/status/fetch.php?pkg=golang-1.24&arch=riscv64&ver=1.24.4-3&stamp=1755794098&raw=0 > > From golang expert and here[0], it seems riscv64 race detector is not > support yet, but not sure which part trigger the test within uploading > recently or other packages. Ideally the test case will be skipped when > memory mapping is not match. Maybe we need to skip it explicitly? > > I will test it with skipping the test case. > > [0]: https://github.com/golang/go/issues/64345
I did some testing of this and found that it seems to work fine on a completely emulated riscv64 VM in QEMU, but on the real hardware that is the ricci porterbox I often got even worse than the buildds and hit segfaults instead that looked like the one in https://github.com/golang/go/issues/57691#issuecomment-2962825755 I was trying to figure out whether my -3 upload is what broke this, but I was ultimately unable to reproduce the same failure the buildds are having on either -3 *or* -1. For what it's worth, both gcc-12 version 12.4.0-8 and 12.5.0-1 were uploaded since the last successful buildd build of src:golang-1.24, so it's possible one of those is related too (the source of libtsan and the error message we're seeing in the tests). I don't think we're intentionally testing the race detector, and my upstream understanding was that they only test/support it on a limited set of architectures anyhow (and it would be surprising IMO for riscv64 to be one of those), but it's also extremely possible I don't know anything. :) https://github.com/golang/go/blob/go1.24.4/src/cmd/dist/test.go#L1677 ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4
