testing: exit status 0xc0000139 with -race + external linking on windows-amd64-2008 #56904
Assignees
Labels
FrozenDueToAge
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
OS-Windows
RaceDetector
Milestone
Comments
thanm
added
the
NeedsInvestigation
|
Change https://go.dev/cl/452763 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Nov 22, 2022
Add a skip for the external-linkage part of the race detector test for elderly versions of windows, until the underlying cause for the problem can be determined. Updates #56904. Change-Id: I3e8650ff66f34efefabcd6bc343d57124539901b Reviewed-on: https://go-review.googlesource.com/c/go/+/452763 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Than McIntosh <thanm@google.com> Auto-Submit: Than McIntosh <thanm@google.com>
|
Change https://go.dev/cl/452769 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Nov 22, 2022
Revise the code added in CL 452763 that skips some of the -race tests on older windows builders. The old-style skip was doing a log.Printf, which wound up being interpreted in "-list" mode. Fix is to pass in a special rtPreFunc when registering the test (thanks Austin for the fix suggestion). Updates #56904. Change-Id: Ia6ea31fb7f011b539173f47357ab3bf7389f256d Reviewed-on: https://go-review.googlesource.com/c/go/+/452769 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Run-TryBot: Than McIntosh <thanm@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Than McIntosh <thanm@google.com>
bcmills
changed the title
|
We're going to stop supporting Windows Server 2008 (https://tip.golang.org/doc/go1.20#windows). Maybe we can just delete that builder? (only run it on 1.19 and 1.20 release branches) |
|
Thanks for the reminder, I agree we should do that. Filed #58008 for tracking it. |
|
Change https://go.dev/cl/467175 mentions this issue: |
johanbrandhorst
pushed a commit
to Pryz/go
that referenced
this issue
Feb 12, 2023
`windows-amd64-2008` builder does no longer exist on go1.20, so it is safe to remove conditions checking for that name. Updates golang#57003 Closes golang#56904 Change-Id: I941ccc64cda0af3b9356996c4b581700afa81987 Reviewed-on: https://go-review.googlesource.com/c/go/+/467175 Run-TryBot: Quim Muntal <quimmuntal@gmail.com> Reviewed-by: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env)?windows/amd64
What did you do?
Run all.bat on windows-amd64-2008-newcc gomote.
What did you expect to see?
All tests passing.
What did you see instead?
With the combination of newer compilers (llvm-based mingw from https://github.com/mstorsjo/llvm-mingw/releases/tag/20220323) and an older Windows image (windows-amd64-2008), some of the race detector tests fail when external linking is in use:
Representative log: https://build.golang.org/log/5dff49b59a3ea310edfd5bb17735f011d3f57420
The two that fail here are os/exec and flag with "-ldflags=-linkmode=external" ; internal linkage works properly.
From what I can tell from googling, "exit status 0xc0000139" is basically a windows loader error; the dynamic loader is unhappy with the binary and won't let it start.
Strangely, I can run the externally linked binary on linux using "wine64", so it appears that this is something specific to the older version of windows.
Comparing the two binaries (from the
llvm-objdump-14 -xoutput), it looks as though the externally linked binary uses a different set of DLLs (both executables use functions fromKERNEL32.dllandmsvcrt.dll, whereas the externally linked one also adds in things fromapi-ms-win-core-synch-l1-2-0.dll.TLS setup also appears different (externally linked version has an explicit
.tlssection and the internally linked one does not). It is possible that this is tickling some sort of windows OS bug; there is a mention in the compiler release notes 'known issues' section that windows native TLS is in use and doesn't work with some older version of windows.The text was updated successfully, but these errors were encountered: