Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
cmd/go: buildmode=pie causes silent failures when using PIE-incompatible C libraries, windows exit status 3221225477 / 0xC0000005 #42233
What version of Go are you using (
Was a %errorlevel% reported?
If the previous command did not succeed could it be possible that test.exe was not what you expected?
Lastly, I’m sorry to ask, but it’s windows, so I must, have you ruled out interference by AV software?
No, install command returned errorlevel 0 when queried. After install, running the executable generated returns a different errorlevel when queried (-1073741819, which I have not found any info on). I get the errorlevel return when using 'go run .' I am hoping the difference in errorlevel between go install, running executable, and go run may be a clue as to where or how it is breaking???
C:\GoPath\src\github.com\axionat\eagle\piglet\libde265\test>go install .
C:\GoPath\src\github.com\axionat\eagle\piglet\libde265\test>ls -l c:\GoPath\bin\test.exe I have unix tools installed in Win
C:\GoPath\src\github.com\axionat\eagle\piglet\libde265\test>go run .
I have run exactly the same commands back and forth with the only change being reinstalling a different go version between the tests with AV and windows firewall all turned off, so I am pretty sure this is not it (but as you say, it is windows... :)
Install thinks is succeeds. My hypothesis is that one of the intermediate steps of the installer is / could be returning an errorlevel that is not checked that is then overwritten by the next step which succeeds with errorlevel 0.
After install I have an 11 kB executable that does nothing (fails before user code with an errorlevel).
Run from 'go install -x":
C:\GoPath\src\github.com\axionat\eagle\piglet\libde265\test>go install -x .
@davecheney I manually ran though the install commands reported by 'go install -a -x -work' related to my packages and had no errors reported, I also checked the windows errorlevel between each step and it was always 0. I am not sure where else to look to find out where it is failing...
I strongly doubt I will be the last person who comes across this problem with the 1.15 migration, so I would offer a couple of thoughts to consider...
The easiest fix would be to go back to buildmode=exe as default windows behavior to maintain compatibility and not break anything for others. (@alexbrainman @ianlancetaylor @bradfitz @FiloSottile discussion on #35192)
If there is consensus that going back to buildmode=exe by default to maintain compatibility is unacceptable or undesirable, then some thoughts / suggestions based on my experience working through this one:
(1) Add a very conspicuous note / caveat to 1.15 release notes along the following lines as a proposed new second paragraph under Ports-Windows:
(2) Does anyone know if there is a way to detect if Cgo imported libraries are pie/aslr compliant so that we can either (a) fail the compilation issuing an error that buildmode=exe is required to support the C libraries or (b) automatically revert to buildmode=exe and issue a warning that buildmode=exe is being used for compliance with C libraries?
(3) If (2) is not simple, is there some way it would be possible to catch this OS error and exit code and generate a useful error or warning instead of a silent crash from the failing program? Something that includes "if you are using Cgo, try buildmode=exe to resolve this issue" would be really nice and helpful here.
Although I am back up and running, I would not recommend closing this issue until at least (1) is done, and hopefully one of (2) and (3) as well if possible.
Given the nature of the failure encountered and the difficulty characterizing it to even search for solutions, my recommendation would be to make a 1.15 minor release that reverts default behavior to buildmode=exe until at least one of (2) or (3) can be completed along with (1) to enable a graceful migration to default behavior of buildmode=pie without difficult to diagnose failures of existing programs.
Thanks all for your quick responses and thoughts.
Sorry you have run into trouble. I hope that people more familiar with Windows will be able to answer your questions. It is extremely unfortunate that linking non-PIE code into a PIE does not produce an error at link time (it does on Unix systems).
I don't think it would be a good idea to change the default build mode in a minor release. That will be confusing in a different way.
Sorry. I did not even looked at your code. I don't have free time.
Yes, that would work for people who use Cgo. But we would have to disable ASLR for every Go user. We provided buildmode=exe fallback specifically for cases like yours. I think our decision is reasonable.
I am not Cgo expert. I don't use if what you say in this paragraph is true. I will let others decide if it is appropriate to include statement likes in the docs.
I do not know, if what you propose is possible. I believe that ASLR is controlled by combination of GCC flags. So it is up to package user / author to set these flags appropriately for their Cgo build.
Again. I am not expert enough to answer your question.