Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
runtime: TestWindowsStackMemoryCgo is flaky #22575
CL 74490 has added TestWindowsStackMemoryCgo that has been flaky. It fails with on windows-386-2008 builder
on windows-amd64-2008 builder
and on windows-amd64-race builder
The error 12 is (from https://docs.microsoft.com/en-us/cpp/c-runtime-library/errno-doserrno-sys-errlist-and-sys-nerr ) ENOMEM Not enough memory.
We also had trybots failed with different message
13 is EACCES Permission denied
pushed a commit
Nov 4, 2017
Copying/updating some discussion from CL 74490.
The order of the failure output strikes me as incredibly odd. First is the final output of the program just before it (in theory) exits, then the output from abort(), which you'd think would kill the program, then the output from the fprintf just before the abort (maybe stderr is buffered, though that would be really annoying).
I'm wondering if the problem is actually that we're creating a thread at program teardown and it has nothing to do with memory. After all, according to the program's own output it should only be using ~10MB of memory.
We've had similar problems in the past with races between
I was going to suggest that it might be an exit vs thread-create as well but I remembered that as being a Linux problem. If there's no check in _cgo_sys_thread_start it certainly seems like there should be. There would probably always be a race window, but at least we can minimize it.
How do I check
Also I still cannot reproduce the failure here. It would be nice to be able to reproduce the failure to make sure we actually fixed it.
I think that particular combination is actually safe (it's exec and thread create on Linux that isn't, or wasn't). Exiting a process on Windows is a complex and decidedly non-atomic process that can race in unfortunate ways with thread creation.
There's actually no race window since we only use this information after CreateThread fails. I suppose technically there's a race the other way: we could incorrectly suppress a true failure when exiting, but I'm okay with that. :)
I would suggest giving