Skip to content

testing: exit status 0xc0000139 with -race + external linking on windows-amd64-2008 #56904

Closed
@thanm

Description

@thanm

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

$ go version
go version devel go1.20-9efc5a5237 Tue Nov 22 14:09:24 2022 +0000 linux/amd64

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:

##### Testing race detector
ok  	runtime/race	12.578s
ok  	flag	1.049s
ok  	net	1.104s
ok  	os	1.144s
ok  	os/exec	2.076s
ok  	encoding/gob	1.069s
exit status 0xc0000139
FAIL	flag	0.010s
exit status 0xc0000139
FAIL	os/exec	0.010s
FAIL
2022/11/21 18:07:39 Failed: exit status 1
go tool dist: FAILED

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 -x output), it looks as though the externally linked binary uses a different set of DLLs (both executables use functions from KERNEL32.dll and msvcrt.dll, whereas the externally linked one also adds in things from api-ms-win-core-synch-l1-2-0.dll.

TLS setup also appears different (externally linked version has an explicit .tls section 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.

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions