Any applications built with race-detector error and fail on startup if using CGO

[Keithcat1]

What version of Go are you using (go version)?

$ go version
go version go1.17 windows/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
set GO111MODULE=auto
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\keith\AppData\Local\go-build
set GOENV=C:\Users\keith\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\py\go\pkg\mod
set GONOPROXY=github.com/keithcat1/nvgo
set GONOSUMDB=github.com/keithcat1/nvgo
set GOOS=windows
set GOPATH=C:\py\go
set GOPRIVATE=github.com/keithcat1/nvgo
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.17
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\keith\AppData\Local\Temp\go-build48417515=/tmp/go-build -gno-record-gcc-switches

What did you do?

Tried to compile a simple CGO program:
hi.go.zip
go build --race hi.go

What did you expect to see?

Hi

What did you see instead?

Some variation of:
==5192==ERROR: ThreadSanitizer failed to allocate 0x0000003d1000 (4001792) bytes at 0x200dcf9fa0000 (error code: 87)

Additional info

I'm using MinGW GCC from winlibs.com

Output of "gcc -v":
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=c:/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/11.2.0/lto-wrapper.exe
OFFLOAD_TARGET_NAMES=nvptx-none
Target: x86_64-w64-mingw32
Configured with: ../configure --prefix=/R/winlibs64_stage/inst_gcc-11.2.0/share/gcc --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --enable-offload-targets=nvptx-
none --with-pkgversion='MinGW-W64 x86_64-posix-seh, built by Brecht Sanders' --with-tune=generic --enable-checking=release --enable-threads=posix --disable-sjlj-excepti
ons --disable-libunwind-exceptions --disable-serial-configure --disable-bootstrap --enable-host-shared --enable-plugin --disable-default-ssp --disable-rpath --enable-li
bstdcxx-pch --enable-libstdcxx-time=yes --disable-libstdcxx-debug --disable-version-specific-runtime-libs --with-stabs --disable-symvers --enable-languages=c,c++,fortra
n,lto,objc,obj-c++,d,jit --disable-gold --disable-nls --disable-stage1-checking --disable-win32-registry --disable-multilib --enable-ld --enable-libquadmath --enable-li
bada --enable-libssp --enable-libstdcxx --enable-lto --enable-fully-dynamic-string --enable-libgomp --enable-graphite --enable-mingw-wildcard --with-mpc=/d/Prog/winlibs
64_stage/custombuilt --with-mpfr=/d/Prog/winlibs64_stage/custombuilt --with-gmp=/d/Prog/winlibs64_stage/custombuilt --with-isl=/d/Prog/winlibs64_stage/custombuilt --ena
ble-install-libiberty --enable-__cxa_atexit --without-included-gettext --with-diagnostics-color=auto --enable-clocale=generic --with-libiconv --with-system-zlib --with-
build-sysroot=/R/winlibs64_stage/gcc-11.2.0/build_mingw/mingw-w64 CFLAGS=-I/d/Prog/winlibs64_stage/custombuilt/include/libdl-win32
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (MinGW-W64 x86_64-posix-seh, built by Brecht Sanders)

[thanm]

@dvyukov per owners

[thanm]

Is this a regression? E.g. were you able to use this new compiler successfully with previous Go releases?

[ALTree]

Likely a dup of #46099.

[thanm]

Thanks @ALTree . Does indeed look very similar.

[Keithcat1]

Nope. I like to upgrade things like Go and GCC quickly so I was likely using GCC 10.3 and Go 1.16. At first I thought that reformatting my PC and installing Windows ten caused this somehow because that's when I remember it starting, but it makes more sense that this could be a compiler bug.

…

On 9/7/21, Than McIntosh ***@***.***> wrote: Thanks @ALTree . Does indeed look very similar. -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #48231 (comment)

[dvyukov]

==5192==ERROR: ThreadSanitizer failed to allocate 0x0000003d1000 (4001792) bytes at 0x200dcf9fa0000 (error code: 87)

This happens when tsan runtime tries to map shadow memory. Reversing the mapping gives application address:

0x200dcf9fa0000/4-0x010000000000 = 0x7f373e7e8000

So windows started mapping binaries at the top of address space, while the runtime expects addresses at the bottom:
https://github.com/llvm/llvm-project/blob/7e8babeb9d55749e3c9cae8802a644c5c96b1942/compiler-rt/lib/tsan/rtl/tsan_platform.h#L429-L438

This probably happens for the .data segment and at least on Linux 0x7f address are used for PIE binaries. So probably gcc started producing PIE binaries on windows by default. Most likely this can be fixed by passing some additional compiler flags. Maybe Go should provide them by default at least for -race mode.

[gopherbot]

Change https://go.dev/cl/420197 mentions this issue: runtime/race: update race_windows_amd64.syso

[thanm]

If you are building Go from source, please try the new race detector runtime (pending submit) to see if it resolves this issue. From your Go repo on windows:

 git fetch https://go.googlesource.com/go refs/changes/97/420197/2 && git checkout FETCH_HEAD

This version of the runtime requires a more up-to-date C compiler version (in particular it requires libsynchronization.a).

[gopherbot]

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)