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

Closed
simonferquel opened this issue Jun 17, 2019 · 9 comments

Comments

@simonferquel
Copy link
Contributor

@simonferquel simonferquel 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
Member

@katiehockman katiehockman commented Jun 17, 2019

@alexbrainman

This comment has been minimized.

Copy link
Member

@alexbrainman alexbrainman 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
Contributor Author

@simonferquel simonferquel 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
Contributor Author

@simonferquel simonferquel 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

@alexbrainman alexbrainman 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
Contributor Author

@simonferquel simonferquel 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
Contributor Author

@simonferquel simonferquel 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
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

@Soar360 Soar360 commented Jul 19, 2019

If you use x86 , that will be good!

simonferquel added a commit to simonferquel/go that referenced this issue Jul 31, 2019
If Go DLL is used by external C program, and lastcontinuehandler
is reached, lastcontinuehandler will crash the process it is
running in.

But it should not be up to Go runtime to decide if process to be
crashed or not - it should be up to C runtime. This CL adjusts
lastcontinuehandler to not to crash when running as DLL.

Fixes golang#32648.
simonferquel added a commit to simonferquel/go that referenced this issue Jul 31, 2019
If Go DLL is used by external C program, and lastcontinuehandler
is reached, lastcontinuehandler will crash the process it is
running in.

But it should not be up to Go runtime to decide if process to be
crashed or not - it should be up to C runtime. This CL adjusts
lastcontinuehandler to not to crash when running as DLL.

Fixes golang#32648.
@gopherbot

This comment has been minimized.

Copy link

@gopherbot gopherbot commented Jul 31, 2019

Change https://golang.org/cl/181839 mentions this issue: runtime: do not crash in lastcontinuehandler when running as DLL

@gopherbot gopherbot closed this in e5e5fb0 Aug 31, 2019
tomocy added a commit to tomocy/go that referenced this issue Sep 1, 2019
If Go DLL is used by external C program, and lastcontinuehandler
is reached, lastcontinuehandler will crash the process it is
running in.

But it should not be up to Go runtime to decide if process to be
crashed or not - it should be up to C runtime. This CL adjusts
lastcontinuehandler to not to crash when running as DLL.

Fixes golang#32648.

Change-Id: Ia455e69b8dde2a6f42f06b90e8af4aa322ca269a
GitHub-Last-Rev: dbdffcb
GitHub-Pull-Request: golang#32574
Reviewed-on: https://go-review.googlesource.com/c/go/+/181839
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
t4n6a1ka added a commit to t4n6a1ka/go that referenced this issue Sep 5, 2019
If Go DLL is used by external C program, and lastcontinuehandler
is reached, lastcontinuehandler will crash the process it is
running in.

But it should not be up to Go runtime to decide if process to be
crashed or not - it should be up to C runtime. This CL adjusts
lastcontinuehandler to not to crash when running as DLL.

Fixes golang#32648.

Change-Id: Ia455e69b8dde2a6f42f06b90e8af4aa322ca269a
GitHub-Last-Rev: dbdffcb
GitHub-Pull-Request: golang#32574
Reviewed-on: https://go-review.googlesource.com/c/go/+/181839
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.