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

Jump to bottom

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

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

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

simonferquel opened this issue Jun 17, 2019 · 9 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.

Comments

@simonferquel
Copy link
Contributor

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
Copy link
Contributor

/cc @ianlancetaylor

@katiehockman katiehockman added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jun 17, 2019
@alexbrainman
Copy link
Member

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
Copy link
Contributor Author

@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
Copy link
Contributor Author

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.

@gopherbot gopherbot mentioned this issue Jun 18, 2019
Closed
@alexbrainman
Copy link
Member

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
Copy link
Contributor Author

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

@simonferquel
Copy link
Contributor Author

got it:

go/src/runtime/runtime2.go

Line 936 in 8f296f5

islibrary bool // -buildmode=c-shared

simonferquel added a commit to simonferquel/go that referenced this issue Jun 19, 2019
@simonferquel
Fix lastcontinuehandler when built as library
78b33c1 
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
Copy link

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
@simonferquel
runtime: do not crash in lastcontinuehandler when running as DLL
e0fd37e 
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
@simonferquel
runtime: do not crash in lastcontinuehandler when running as DLL
a5f71ea 
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
Copy link

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

tomocy pushed a commit to tomocy/go that referenced this issue Sep 1, 2019
@simonferquel @tomocy
runtime: do not crash in lastcontinuehandler when running as DLL
c47d543 
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 pushed a commit to t4n6a1ka/go that referenced this issue Sep 5, 2019
@simonferquel @t4n6a1ka
runtime: do not crash in lastcontinuehandler when running as DLL
57b1bc7 
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>
@golang golang locked and limited conversation to collaborators Aug 30, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

runtime: do not crash in lastcontinuehandler when running as DLL simonferquel/go
5 participants
@simonferquel @gopherbot @alexbrainman @Soar360 @katiehockman