You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Does this issue reproduce with the latest release?
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
set GOROOT=C:\Program Files\Go
set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
set CGO_CFLAGS=-O2 -g
set CGO_CXXFLAGS=-O2 -g
set CGO_FFLAGS=-O2 -g
set CGO_LDFLAGS=-O2 -g
set GOGCCFLAGS=-m64 -mthreads -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=c:\temp\go-build2999029303=/tmp/go-build -gno-record-gcc-switches
What did you do?
The following code crashes when "var testingWER bool" at "runtime/signal_windows.go:168" is false.
Changing "var testingWER bool" to true, makes the application work fine.
What did you expect to see?
That it doesn't crash
What did you see instead?
JNI_CreateJavaVM crashes with ACCESS_VIOLATION.
The problem is that an ACCESS_VIOLATION generated by JNI (and caught by it) is not getting caught, due to the fact that Go doesn't continue the exception search (i.e. _EXCEPTION_CONTINUE_SEARCH).
Patching Go to "testingWER=true" forces Go to continue the search, allowing JNI to handle the error.
As a short term solution, I suggest making "testingWER" public, so developers can workaround unexpected issues without patching Go.
As a long term solution, signal_windows.go return _EXCEPTION_CONTINUE_SEARCH in case the Go module is a library or an archive. I suggest doing one of the following
Return _EXCEPTION_CONTINUE_SEARCH if CGo is being used, as stepping out of "Go runtime" might require custom handling of an exception.
Provide a function to the user to replace "lastcontinuehandler" in signal_windows.go with their own. I think this is the best option, as we reach this point after Go realizes it cannot handle the exception, so let the user take some action. You can also pass as a parameter to the user's custom "lastcontinuehandler" the code which throws the exception (the winthrow() function).
The text was updated successfully, but these errors were encountered: