/cc @alexbrainman

If I comment out TestRaiseException in src/runtime/syscall_windows_test.go then everything else worked. Code compiled, tests passed, and install finished. So it seems to be a problem local to the RaiseException procedure.

Unfortunately the test output doesn't provide more useful details so I can't locate the root of cause. Please try to reproduce the error, if not I can provide more detailed information of my environment.

I have no idea why test fails on your computer. Sorry.

Alex

@rixtox you can try and debug this https://play.golang.org/p/Ie_6Cg3NXYK program. It prints this

Exception 0xbad 0xdd283a1cf833 0x1 0x7ffabd089129
PC=0x7ffabd089129

syscall.Syscall6(0x7ffabfdee490, 0x4, 0xbad, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
        /home/a/go/src/runtime/syscall_windows.go:197 +0xea
syscall.(*Proc).Call(0xc00004e200, 0xc0000500e0, 0x4, 0x4, 0x0, 0x0, 0x0, 0x46a2a0)
        /home/a/go/src/syscall/dll_windows.go:177 +0x375
main.main()
        /home/a/src/issues/go/32036/main.go:11 +0xf2
rax     0x75f8a0
rbx     0x4db0d0
rcx     0x75f700
rdi     0x2a5000
rsi     0xc00002be58
rbp     0xc00002be08
rsp     0x75fd30
r8      0x10004
r9      0x8
r10     0x75f510
r11     0x0
r12     0xffffffffffffffff
r13     0x8
r14     0x7
r15     0x100
rip     0x7ffabd089129
rflags  0x202
cs      0x33
fs      0x53
gs      0x2b

here.

What does it prints for you?

Alex

Here's the output:

Exception 0xbad 0x909f3a4b7102 0x5 0x7ff8f2889129
PC=0x7ff8f2889129

syscall.Syscall6(0x7ff8f5d4e490, 0x4, 0xbad, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
        C:/projects/c/go/src/runtime/syscall_windows.go:197 +0xea
syscall.(*Proc).Call(0xc000004240, 0xc00000e5c0, 0x4, 0x4, 0x0, 0x0, 0x0, 0x46a2a0)
        C:/projects/c/go/src/syscall/dll_windows.go:177 +0x375
main.main()
        C:/Users/root/Desktop/xxx.go:11 +0xf2
rax     0x75f5b8
rbx     0x4db0d0
rcx     0x0
rdi     0x345000
rsi     0xc000041e58
rbp     0xc000041e08
rsp     0x75fd30
r8      0x300000002
r9      0x2
r10     0x1536cd652
r11     0x345000
r12     0xffffffffffffffff
r13     0x2f
r14     0x2e
r15     0x100
rip     0x7ff8f2889129
rflags  0x206
cs      0x33
fs      0x53
gs      0x2b

Which is actually the expected output.

@alexbrainman
I modified the test code to retain the generated exe during testing stage, and here's what I got:
https://send.firefox.com/download/c1666828aa7a14a1/#FCstiyF2dLzc52RwStpgRg

Sorry for sending an exe file but I can't think of other way to demonstrate this problem.

Running testprog.exe RaiseException gives empty output.

OK I found another way to demonstrate it.

So I first compiled the master branch by commenting out the failing test.
Then I set GOROOT to the master source code directory, and use the compiled go.exe in the bin directory of the master source code directory.

Then under src/runtime/testdata/testprog I run:

$ C:\projects\c\go\bin\go.exe version
go version devel +14491a2ec4 Wed May 15 19:53:28 2019 +0000 windows/amd64
$ C:\projects\c\go\bin\go.exe build .
$ .\testprog.exe RaiseException

Now the compiled program outputs empty.

Sorry for sending an exe file but I can't think of other way to demonstrate this problem.

I won't run you executable. Sorry.

So I first compiled the master branch by commenting out the failing test.

I hope you know that you don't need to run tests to "compile" Go. Tests are run to verify that all build tools and libraries work as expected. You can build Go by just running

cd %GOROOT%\src
make

I looked at the test. And it does approximately this

c:\>cd %GOROOT%\src\runtime\testdata\testprog

c:\Users\Alex\dev\go\src\runtime\testdata\testprog>go build -o %TMP%\a.exe

c:\Users\Alex\dev\go\src\runtime\testdata\testprog>%TMP%\a.exe RaiseException
Exception 0xbad 0x705dc70a2c0e 0xb 0x7ffabd089129
PC=0x7ffabd089129

syscall.Syscall6(0x7ffabfdee490, 0x4, 0xbad, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
        c:/users/alex/dev/go/src/runtime/syscall_windows.go:197 +0xea
syscall.(*Proc).Call(0xc000054480, 0xc00005c140, 0x4, 0x4, 0x0, 0x0, 0xc00004f6e8, 0x360000c00004a9c0)
        c:/users/alex/dev/go/src/syscall/dll_windows.go:177 +0x375
main.RaiseException()
        c:/users/alex/dev/go/src/runtime/testdata/testprog/syscall_windows.go:25 +0xf2
main.main()
        c:/users/alex/dev/go/src/runtime/testdata/testprog/main.go:34 +0x1d3
rax     0x8df8a0
rbx     0x5f0c10
rcx     0x8df700
rdi     0x23a000
rsi     0xc000089db0
rbp     0xc000089d60
rsp     0x8dfd30
r8      0x2000
r9      0x0
r10     0x11b
r11     0xdf01d8
r12     0xffffffffffffffff
r13     0xb
r14     0xa
r15     0x100
rip     0x7ffabd089129
rflags  0x202
cs      0x33
fs      0x53
gs      0x2b

c:\Users\Alex\dev\go\src\runtime\testdata\testprog>

I also noticed that your output contains $, like

$ C:\projects\c\go\bin\go.exe version

What kind of shell is that? Go executable are Windows execrable - they require standard Windows environment to run in. TestRaiseException actually requires that Windows exception handling work as standard. Maybe your shell affects that.

Alex

@alexbrainman

I hope you know that you don't need to run tests to "compile" Go. Tests are run to verify that all build tools and libraries work as expected.

Yes I know, and I'm already using the compiled go for my project development. But it doesn't mean the failing test should be dismissed just because it doesn't affects my usage.

What kind of shell is that?

It's a normal Windows CMD.exe shell, just running inside ConEmu so it has that $ prompt symbol.

So I've tested both the testprog and your code https://play.golang.org/p/Ie_6Cg3NXYK in one same CMD shell session as follows:

$ SET GOROOT=C:\projects\c\go
$ cd %GOROOT%\src\runtime\testdata\testprog
$ %GOROOT%\bin\go build
$ .\testprog.exe RaiseException
$ cd %USERPROFILE%\Desktop
$ %GOROOT%\bin\go build raise_exception.go
$ .\raise_exception.exe
Exception 0xbad 0xc24b80ecdfcf 0x5 0x7ffeb1b19129
PC=0x7ffeb1b19129

syscall.Syscall6(0x7ffeb2a3e490, 0x4, 0xbad, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
        C:/projects/c/go/src/runtime/syscall_windows.go:197 +0xea
syscall.(*Proc).Call(0xc000004240, 0xc00000e5c0, 0x4, 0x4, 0x0, 0x0, 0x0, 0x46a2a0)
        C:/projects/c/go/src/syscall/dll_windows.go:177 +0x375
main.main()
        C:/Users/root/Desktop/raise_exception.go:11 +0xf2
rax     0x75f5b8
rbx     0x4db0d0
rcx     0x0
rdi     0x21a000
rsi     0xc000041e58
rbp     0xc000041e08
rsp     0x75fd30
r8      0x300000002
r9      0x2
r10     0x1536cd652
r11     0x21a000
r12     0xffffffffffffffff
r13     0x2f
r14     0x2e
r15     0x100
rip     0x7ffeb1b19129
rflags  0x206
cs      0x33
fs      0x53
gs      0x2b

As you can see, your code raise_exception.go runs fine, as Exception 0xbad is printed. But the testprog, although compiled in the exact same environment, prints empty output.

As you can see, your code raise_exception.go runs fine, as Exception 0xbad is printed. But the testprog, although compiled in the exact same environment, prints empty output.

Same code, but its executed differently. Your raise_exception program is executed directly by your shell. But testprog is started by shell, and then testprog creates another process that runs code that does the testing. Perhaps something goes amiss when child process gets created. Perhaps some environment variable missing from child process. Perhaps child process stdio / stdout / stderr redirection is broken.

Alex

@alexbrainman

But testprog is started by shell, and then testprog creates another process that runs code that does the testing.

That's how TestRaiseException behaves, not testprog. testprog is the child process started by TestRaiseException, it doesn't start any other child process.

But you are right about the shell environment though. I started a CMD shell outside of ConEmu and testprog outputs correctly.

And if I change your code to https://play.golang.org/p/lg-zJKObRMX, by importing the os module, inside CMD in ConEmu, it behaves the same as testprog, printing empty output.

So I suspect something in the os module affected the RaiseException behavior and under CMD inside ConEmu such effect would break the output.

So I suspect something in the os module affected the RaiseException behavior and under CDM inside ConEmu such effect would break the output.

I do not know what your problem is.

Alex

I will close this issue until someone willing to investigate further to reopen it.

I'm not sure I understand why you closed this. If this is a real issue it should remain open. If it no longer occurs, then it's fine to close it.