Comment 1:

Mentioned at https://groups.google.com/d/msg/golang-nuts/eeOHNw_shwU/BbQHNu0EHCUJ
Alex

Comment 2:

The link error is easy: the mingw being used is too old, and a newer one must be used if
you want to run the tests. Updating would probably bring fewer gcc bugs too.
But the builders have the new enough mingw and are still seeing failures when the test
executes. I am co-opting this issue for that problem, which I do not understand.
Here is an execution failure.
http://build.golang.org/log/9668ce8fb8053933ba0782562a271078b9205811
The runtime frames are missing.
The runtime frames are controlled by setting the GOTRACEBACK environment variable to 2.
The run.bat script does this when running misc/cgo/test.
The test itself checks os.Getenv("GOTRACEBACK") == "2" before starting the test.
So %GOTRACEBACK% *is* 2, but the runtime is still not printing frames.
It looks to me like on Windows the runtime uses env_posix.go but should
really be using a Windows-specific implementation of getenv.
Like on Plan 9, I don't believe the environment is just handed to the process on startup.
Instead the getenv implementation should do what syscall.Getenv does.
(Perhaps there are ASCII versions that can be used to avoid the UTF-16 decoding.)
Great story, except that somehow this test is passing at tip.
Why does runtime.getenv work on Windows at tip but apparently not work on the 1.3
release branch?

Labels changed: added release-go1.3.3.

Status changed to Accepted.

Comment 3:

I will investigate, if you like.
Alex

Comment 4:

Please do. Thank you!

Comment 5:

> ... Why does runtime.getenv work on Windows at tip but apparently not work on the 1.3
release branch?
release version iterates over syscall.envs (that is not set on windows), while tip uses
runtime.envs that is set in os_windows.c.
Do you want me to continue?
Alex

Comment 6:

runtime.envs at tip is supposed to be the same as syscall.envs in 1.3.
In particular, in 1.3, os_windows.c's runtime.goenvs sets up syscall.envs.
It's a bit confusing, which is part of why tip now uses runtime vars for everything.
I see the problem now. traceback_cache is not reset after parsing envs on Windows, like
it in goenvs_unix.
Thank you.

Comment 7:

You are right, I am wrong. As always. :-)
Alex

Comment 8:

Well, you were right that syscall.envs is not set on windows at the time that it is
consulted. That's the problem. Thank you very much.

Comment 9:

Any time.
Alex

Comment 10:

CL 152760043 should help.

Comment 11:

CL https://golang.org/cl/152760043 mentions this issue.

Comment 12:

This issue was closed by revision 6ee8ec277a21.

Status changed to Fixed.