Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
Keithcat1 opened this issue Sep 7, 2021 · 9 comments
Closed

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

Keithcat1 opened this issue Sep 7, 2021 · 9 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. RaceDetector WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Milestone
Backlog

Comments

@Keithcat1
Copy link

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 thanm added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Sep 7, 2021
@thanm thanm added this to the Backlog milestone Sep 7, 2021
@thanm
Copy link
Contributor

thanm commented Sep 7, 2021

@dvyukov per owners

@thanm
Copy link
Contributor

thanm commented Sep 7, 2021

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

@ALTree
Copy link
Member

ALTree commented Sep 7, 2021

Likely a dup of #46099.

@thanm
Copy link
Contributor

thanm commented Sep 7, 2021

Thanks @ALTree . Does indeed look very similar.

@Keithcat1
Copy link
Author

Keithcat1 commented Sep 9, 2021 via email

@dvyukov
Copy link
Member

dvyukov commented Sep 17, 2021

==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.

@thanm thanm mentioned this issue Jun 30, 2022
Closed
@gopherbot
Copy link

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

@thanm
Copy link
Contributor

thanm commented Jul 31, 2022

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).

@thanm thanm added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Dec 6, 2022
@gopherbot
Copy link

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.)

gopherbot pushed a commit that referenced this issue Jan 25, 2023
@thanm
runtime/race: update race_windows_amd64.syso
cc82867 
Update race_windows_amd64.syso to latest tsan (V3) runtime.

This version of the runtime depends on libsynchronization.a, so to
use this syso, you need to also be using a sufficiently up to date
version of GCC (notably GCC 5.1, installed on the Go windows builders
right now, does not include this library).

Updates #48231.
Updates #35006.
Fixes #49761.

Change-Id: Ia1e2b1d8fe7e2c99728150734935a2c522006caa
Reviewed-on: https://go-review.googlesource.com/c/go/+/420197
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
@golang golang locked and limited conversation to collaborators Jan 6, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. RaceDetector WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests
5 participants
@dvyukov @ALTree @gopherbot @thanm @Keithcat1