-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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
Comments
(CC @golang/windows) |
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? |
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.
If you were patching Go before, I suggest you to continue doing that, i.e. readding |
Hi, |
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. |
Change https://go.dev/cl/457875 mentions this issue: |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat 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.
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
The text was updated successfully, but these errors were encountered: