Skip to content
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.

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

runtime: On Windows, lastcontinuehandler intercepts exception raised in non-go code #32648

Open
simonferquel opened this issue Jun 17, 2019 · 8 comments

Comments

Projects
None yet
4 participants
@simonferquel
Copy link

commented Jun 17, 2019

What version of Go are you using (go version)?

$ go version
go version go1.12 windows/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\simon\AppData\Local\go-build
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=c:\gohome
set GOPROXY=
set GORACE=
set GOROOT=c:\go
set GOTMPDIR=
set GOTOOLDIR=c:\go\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\simon\AppData\Local\Temp\go-build415554718=/tmp/go-build -gno-record-gcc-switches

What did you do?

I have built a GO program that calls C# code using CGO. When the .Net debugger is attached to the process, when any .net code is called, I get a panic like with the following trace:

Exception 0x80000003 0x0 0x0 0x7ffcd17d4052
PC=0x7ffcd17d4052

runtime: unknown pc 0x7ffcd17d4052
stack: frame={sp:0x87fd58, fp:0x0} stack=[0x0,0x87fdc0)
000000000087fc58:  0000000000000190  0000000002030000
000000000087fc68:  0000000000000000  000000000087fc90
000000000087fc78:  0000000000000003  0000000000000001
000000000087fc88:  00007ffcd3beae06  0000000000000004
000000000087fc98:  0000000000004000  00007ffcd3d4d000
000000000087fca8:  0000000000000003  00007ffcd3d4d3e0
000000000087fcb8:  00007ffcd3c4ed63  0000000000980740
000000000087fcc8:  000000c00004fed0  000000c00004fed0
000000000087fcd8:  00000000004c0000 <flag.(*FlagSet).parseOne+880>  0000000000000000
000000000087fce8:  000000c00004ffd0  0000000000000000
000000000087fcf8:  000000c00004ffc0  0000000002030000
000000000087fd08:  0000000000000000  000000c000050000
000000000087fd18:  00000000005070e5  000000c00004fed0
000000000087fd28:  000000c00004fe90  000000c00004fed0
000000000087fd38:  0000000000000000  000000c00004fed0
000000000087fd48:  00000000006595c0  000000c00004fed0
000000000087fd58: <000000000045b9f3 <runtime.asmcgocall+115>  0000000000000000
000000000087fd68:  0000000000000000  0000000000000000
000000000087fd78:  0000000000000001  000000c00004fe08
000000000087fd88:  00000000000001a0  000000c00003f200
000000000087fd98:  0000000000434bb0 <runtime.mstart+0>  0000000000172480
000000000087fda8:  000000000045a02c <runtime.rt0_go+332>  0000000000172480
000000000087fdb8:  000000000045a033 <runtime.rt0_go+339>
runtime: unknown pc 0x7ffcd17d4052
stack: frame={sp:0x87fd58, fp:0x0} stack=[0x0,0x87fdc0)
000000000087fc58:  0000000000000190  0000000002030000
000000000087fc68:  0000000000000000  000000000087fc90
000000000087fc78:  0000000000000003  0000000000000001
000000000087fc88:  00007ffcd3beae06  0000000000000004
000000000087fc98:  0000000000004000  00007ffcd3d4d000
000000000087fca8:  0000000000000003  00007ffcd3d4d3e0
000000000087fcb8:  00007ffcd3c4ed63  0000000000980740
000000000087fcc8:  000000c00004fed0  000000c00004fed0
000000000087fcd8:  00000000004c0000 <flag.(*FlagSet).parseOne+880>  0000000000000000
000000000087fce8:  000000c00004ffd0  0000000000000000
000000000087fcf8:  000000c00004ffc0  0000000002030000
000000000087fd08:  0000000000000000  000000c000050000
000000000087fd18:  00000000005070e5  000000c00004fed0
000000000087fd28:  000000c00004fe90  000000c00004fed0
000000000087fd38:  0000000000000000  000000c00004fed0
000000000087fd48:  00000000006595c0  000000c00004fed0
000000000087fd58: <000000000045b9f3 <runtime.asmcgocall+115>  0000000000000000
000000000087fd68:  0000000000000000  0000000000000000
000000000087fd78:  0000000000000001  000000c00004fe08
000000000087fd88:  00000000000001a0  000000c00003f200
000000000087fd98:  0000000000434bb0 <runtime.mstart+0>  0000000000172480
000000000087fda8:  000000000045a02c <runtime.rt0_go+332>  0000000000172480
000000000087fdb8:  000000000045a033 <runtime.rt0_go+339>

When using .Net core instead of the full .Net framework, the same problem occurs as soon as a breakpoint is hit in C# code.

I can also reproduce the error by attaching Visual C++ debugger and using CGO to call C code calling DebugBreak

What did you expect to see?

Using another language debugger on a GO program to break on code called using CGO should work without crashing the go runtime.

What did you see instead?

Using another language debugger on a GO program (to debug non-go code called using CGO), crashes my program any time an exception of type EXCEPTION_BREAKPOINT is raised.

Candidate fix

This behavior is fixed in #32574, although it might have undesired side effects I am not aware of.

@katiehockman

This comment has been minimized.

Copy link
Contributor

commented Jun 17, 2019

@alexbrainman

This comment has been minimized.

Copy link
Member

commented Jun 18, 2019

Thank you for raising this issue @simonferquel

Unfortunately I still don't see what your problem is. Can you, please, provide all steps I need to reproduce it. Including all source code and tools I need.

Thank you.

Alex

@simonferquel

This comment has been minimized.

Copy link
Author

commented Jun 18, 2019

@alexbrainman sure, no problem. I'll setup a github repo with a repro, and a quick video highlighting the issue. Thanks for taking the time to investigate this with me, this could open the door to better cross-language interop and debugging experience.

@simonferquel

This comment has been minimized.

Copy link
Author

commented Jun 18, 2019

Here is the repro: https://github.com/simonferquel/golang-continue-handler-repro
I've added a walk-through video in it explaining the issue (sorry for my english in there, I am not a native english speaker).

If you want to run the example, you'll need:

VS code tasks are setup, so that hitting ctrl+f5 will start without debugging, and f5 will start with the dotnet core debugger (add a break point at https://github.com/simonferquel/golang-continue-handler-repro/blob/master/csharp/Program.cs#L19, to reproduce the issue).
The breakpoint is hit correctly, but resuming execution crashes the program, because the BREAKPOINT exception is incorrectly trapped by the lastcontinuehandler.

@alexbrainman

This comment has been minimized.

Copy link
Member

commented Jun 19, 2019

Here is the repro: https://github.com/simonferquel/golang-continue-handler-repro
I've added a walk-through video in it explaining the issue

I can see the problem, thank you very much. You are using Go dll, not Go executable. This is very different - C# runtime should be in control of what happens inside of C# process, not Go runtime. I will comment on https://go-review.googlesource.com/c/go/+/181839 about what to do next.

Alex

@simonferquel

This comment has been minimized.

Copy link
Author

commented Jun 19, 2019

Hmm that makes perfect sense. How can I determine that I am running a dll? Some global var in runtime?

@simonferquel

This comment has been minimized.

Copy link
Author

commented Jun 19, 2019

got it:

islibrary bool // -buildmode=c-shared

simonferquel added a commit to simonferquel/go that referenced this issue Jun 19, 2019

Fix lastcontinuehandler when built as library
When a golang package is built as a c-shared or c-archive for being
loaded in a non-go program, it should not crash the program when an
exception is observed, but let the main program runtime decide what to
do.

This fixes this behavior for c-shared/c-archive on Windows

fix golang#32648

Signed-off-by: Simon Ferquel <simon.ferquel@docker.com>
@Soar360

This comment has been minimized.

Copy link

commented Jul 19, 2019

If you use x86 , that will be good!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.