Skip to content

runtime: TestRaiseException fails on windows server 2003 (amd64) #10162

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
minux opened this issue Mar 14, 2015 · 8 comments
Closed

runtime: TestRaiseException fails on windows server 2003 (amd64) #10162

minux opened this issue Mar 14, 2015 · 8 comments
Labels
FrozenDueToAge
Milestone
Go1.5

Comments

@minux
Copy link
Member

minux commented Mar 14, 2015

This program:

package main
import "syscall"
func main() {
        const EXCEPTION_NONCONTINUABLE = 1
        mod := syscall.MustLoadDLL("kernel32.dll")
        proc := mod.MustFindProc("RaiseException")
        proc.Call(0xbad, EXCEPTION_NONCONTINUABLE, 0, 0)
        println("RaiseException should not return")
}

when running standalone, doesn't output anything on windows server 2003.
however, when running inside gdb, it correct output unexpected signal during cgo execution
message.

Moreover, if I add a println statement before proc.Call, the program will also be working
as intended when running standalone.

/cc @alexbrainman
@minux minux added this to the Go1.5 milestone Mar 14, 2015
@kardianos
Copy link
Contributor

On windows 2003 32-bit, tip prints this for me for the given program above:

Exception 0xbad 0x4086ce 0x427608 0x77e4bee7
PC=0x77e4bee7
signal arrived during cgo execution

syscall.Syscall6(0x77e4beab, 0x4, 0xbad, 0x1, 0x0, 0x0, 0x0, 0x0, 0x10a235a0, 0x
7c8285ec, ...)
C:/dev/go/src/runtime/syscall_windows.go:139 +0x5f
syscall.(*Proc).Call(0x10a2a090, 0x10a43fac, 0x4, 0x4, 0x43ddbe, 0x10a235a8, 0x0
, 0x0)
C:/dev/go/src/syscall/dll_windows.go:136 +0x46b
main.main()
C:/dev/test/bug1/main.go:9 +0x98
eax 0x6fe84
ebx 0x10a43ef0
ecx 0x0
edx 0x10a43ec8
edi 0x6feec
esi 0x0
ebp 0x6fed4
esp 0x6fe80
eip 0x77e4bee7
eflags 0x246
cs 0x1b
fs 0x3b
gs 0x5480000

@kardianos
Copy link
Contributor

Doh.
I just saw your platform.
I'll test on amd64 next.

@kardianos
Copy link
Contributor

I can repo on amd64 on XP/2003. This is not a problem on 386 OS or on amd64 OS running 386 code. This is not a problem on newer amd64 windows platform. This is a regression from the 1.4.2 release.

In runtime/os1_windows_amd64.go func exception handler:
the exception does not originate from go so the first branch is rightly taken. However it fails to call "lastcontinuehandler" like it should later. If the first branch returns CONTINUE_EXECUTION then the registers are printed.

@bradfitz
Copy link
Contributor

Opened #10267 to track running a Windows Server 2003 builder.

@alexbrainman
Copy link
Member

@kardianos thank you for looking into this. You say "This is a regression from the 1.4.2 release". Do you mean that the program above prints stack trace if compiled with go.1,4,2, but prints nothing with current tip? I suspect it prints nothing with any version.

I think it is the way your Windows works. Does your Windows have AddVectoredContinueHandler API (see os_init function)? Perhaps it is environment combination I didn't see before: amd64 and no AddVectoredContinueHandler. Perhaps that combination does not work with current code as it is written.

Alex

@bradfitz bradfitz mentioned this issue Mar 27, 2015
Closed
@kardianos
Copy link
Contributor

@alexbrainman That is correct. With 1.4.2 it opens up a "report error" dialog, but then it prints the register dump. Yes, 2003/XP -64bit does have a AddVectoredContinueHandler API.

If a don't disable Windows Error Reporting dialog, then the 1.4.2 behavior is restored: the dialog is displayed, but the dump is also displayed. I presume there is a bug in this version where the continue handler is not called if the dialog is not displayed.

One option would be to detect the Windows version number and not use the AddVectoredContinueHandler in amd64 2003/XP as it appears to have a bug.

-Daniel

@alexbrainman
Copy link
Member

@kardianos I am confused, but it does not matter. I will try to find computer to debug this on. Alternatively, if you want to try and fix it yourself, I am fine with that. I think we have enough tests so we won't break any working OSes. Naturally any new tests are welcome.

Alex

@kardianos
Copy link
Contributor

Fair enough. I've got a change that works around the problem. Probably not
the greatest approach.
https://go-review.googlesource.com/8165
But if the approach looks alright I can add test as well.

On Fri, Mar 27, 2015 at 5:15 PM Alex Brainman notifications@github.com
wrote:

@kardianos https://github.com/kardianos I am confused, but it does not
matter. I will try to find computer to debug this on. Alternatively, if you
want to try and fix it yourself, I am fine with that. I think we have
enough tests so we won't break any working OSes. Naturally any new tests
are welcome.

Alex

—
Reply to this email directly or view it on GitHub
#10162 (comment).

@golang golang locked and limited conversation to collaborators Jun 25, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Go1.5
Development

No branches or pull requests
5 participants
@bradfitz @minux @kardianos @gopherbot @alexbrainman