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: Go crashes in windows when creating JVM using "JNI_CreateJavaVM" #58542

Open
GreenFuze opened this issue Feb 15, 2023 · 8 comments
Open
Assignees
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-Windows
Milestone

Comments

@GreenFuze
Copy link

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

$ go version
go version go1.20 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 GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\green\AppData\Local\go-build
set GOENV=C:\Users\green\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\green\go\pkg\mod
set GONOPROXY=github.com/MetaFFI/*,github.com/GreenFuze/*
set GONOSUMDB=github.com/MetaFFI/*,github.com/GreenFuze/*
set GOOS=windows
set GOPATH=C:\Users\green\go
set GOPRIVATE=github.com/MetaFFI/*,github.com/GreenFuze/*
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Program Files\Go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.20
set GCCGO=gccgo
set GOAMD64=v1
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=NUL
set GOWORK=
set CGO_CFLAGS=-O2 -g
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-O2 -g
set CGO_FFLAGS=-O2 -g
set CGO_LDFLAGS=-O2 -g
set PKG_CONFIG=pkg-config
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.

package main

/*
#include <Windows.h>
#include <stdio.h>

typedef struct JavaVMInitArgs {
    int version;

    int nOptions;
    void *options;
    unsigned char ignoreUnrecognized;
} JavaVMInitArgs;

void create_jvm()
{
	HMODULE h = LoadLibrary("C:\\Program Files\\Microsoft\\jdk-11.0.18.10-hotspot\\bin\\server\\jvm.dll");
	void* create = GetProcAddress(h, "JNI_CreateJavaVM");

	JavaVMInitArgs vm_args;
    vm_args.version = 0x000a0000; //JNI_VERSION_10
    vm_args.nOptions = 0;
    vm_args.options = 0;
    vm_args.ignoreUnrecognized = 0;

    void* pjvm = 0;
    void* penv = 0;

	printf("Before calling JNI_CreateJavaVM\r\n");
    ((void(*)(void**, void**, JavaVMInitArgs*))create)(&pjvm, &penv, &vm_args);
	printf("After calling JNI_CreateJavaVM\r\n");
}
*/
import "C"

func main(){
	C.create_jvm();
}

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.

Resolution Suggestions

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

  1. Return _EXCEPTION_CONTINUE_SEARCH if CGo is being used, as stepping out of "Go runtime" might require custom handling of an exception.
  2. 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).
@bcmills
Copy link
Contributor

bcmills commented Feb 15, 2023

(CC @golang/windows)

@bcmills bcmills changed the title Go crashes in windows when creating JVM using "JNI_CreateJavaVM" runtime: Go crashes in windows when creating JVM using "JNI_CreateJavaVM" Feb 15, 2023
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Feb 15, 2023
@bcmills
Copy link
Contributor

bcmills commented Feb 15, 2023

Compare #57441, #52763, #19465.

@qmuntal
Copy link
Contributor

qmuntal commented Feb 16, 2023

Also related to #56082 #47576 and #12516

@thanm thanm added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Feb 21, 2023
@mknyszek mknyszek added this to the Backlog milestone Feb 22, 2023
@GreenFuze
Copy link
Author

In version go1.21.1, testingWER has been removed, but JVM still crashes. Currently I cannot find a workaround to load JVM using JNI_CreateJavaVM in windows.

Can anyone offer a workaround?

@qmuntal
Copy link
Contributor

qmuntal commented Sep 27, 2023

I have some CLs (CL 525475 and CL 457875) in flight that will teach the Go runtime to not crash when an exception is catch and handled by a SEH exception handler. This should fix your issue.

Can anyone offer a workaround?

If you were patching Go before, I suggest you to continue doing that, i.e. readding testingWER.

@mpetavy
Copy link

mpetavy commented Nov 24, 2023

Hi,
wanted to ask if there will be a fix in a next GO release in the near future with the fixes as mentioned above?
Thanks for an update.

@qmuntal
Copy link
Contributor

qmuntal commented Nov 24, 2023

Not yet, I couldn't land CL 457875 in time because I got sidetracked by an important missing piece in the SEH machinery (see CL 534555).

My plan is to fix this issue in go 1.23.

@qmuntal qmuntal self-assigned this Nov 24, 2023
@qmuntal qmuntal modified the milestones: Backlog, Go1.23 Nov 24, 2023
@gopherbot
Copy link
Contributor

Change https://go.dev/cl/457875 mentions this issue: runtime,cmd/link: use SEH instead of vectored exception handlers

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-Windows
Projects
Status: In Progress
Development

No branches or pull requests

7 participants