signal arrived during external code execution #31
Comments
|
Hi, Are you talking about the exaple from the readme (https://github.com/timob/jnigi/blob/master/README.md#example)? If you are using Oracle JVM, you could try OpenJDK instead. Also you can try adding options to |
|
Hi, |
|
Can you post the code that causes this please? |
|
Seems like I am affected in exactly same way on Windows. Same code on Linux target works. Exception 0xc0000005 0x0 0x0 0x25ce5f60764 @timob: As it may be version related. On which go/gcc/jvm version it's confirmed to work? I may try to downgrade and compile with these versions to rule out GO/GCC regression. Tried the usual workarounds with this exception but none of them worked out. Init code is damn simple: |
|
I am getting this as well. To fix you need to make a change to your Go install on Windows and recompile: Here: This disables some of the Go exception handling. There is an issue about exception handling in Go on Windows: During I made that change and sucessfully ran |
|
Thank you I confirm provided runtime fix workarounds problem on windows. On the other side looked inside go and jvm internals and not absolutely sure it's really safe (I do not pretend to understand that low level) The funny things is windows jvm code path has exception wrapper( confirmed in jvm source and described here https://www.oracle.com/java/technologies/javase/signals.html). May it be incomplete go check here https://github.com/golang/go/blob/master/src/runtime/signal_windows.go#L66 ? As long as I understand go is configuring itself as vectored SEH which kicks-in before JVM exception handler and may explain why it panics unnecessarily. What I was looking for is a workaround without changing GO runtime. Having some problems with gdb so cannot confirm or reject the hypothesis. |
|
Can anyone test with https://go-review.googlesource.com/c/go/+/195577/ ? I might do this once I have time. |
|
Hi。I encountered the same problem。Can you help with the problem。 go version java version |
|
This is still a problem in version go1.21rc4. The problem is that OpenJDK DLL on windows uses SEH to trap exceptions, and then triggers exceptions on CreateJavaVM to test for OS bugs with exception handling, see https://stackoverflow.com/questions/36250235/exception-0xc0000005-from-jni-createjavavm-jvm-dll. Go uses VEH on Windows and doesn't pass on exceptions to SEH, even on non go exceptions, it seems. There does seem to be code to handle this problem for a specific case on arm64 https://github.com/golang/go/blob/3393155abf77e460fe661ffccb0b21c500290613/src/runtime/signal_windows.go#L300. Maybe we could propose the same for OpenJDK DLL: // OpenJDK JVM DLL uses SEH to trap segfaults during runtime
// initialization to test for OS bugs related to signal handling.
// On x86, non go exception, assume this and pass onward to SEH.
if (GOARCH == "amd64" || GOARCH == "386") && info.exceptioncode == _EXCEPTION_ACCESS_VIOLATION &&
(r.ip() < firstmoduledata.text || firstmoduledata.etext < r.ip()) {
return _EXCEPTION_CONTINUE_SEARCH
}This means that Go exceptions would be handled in the normal way and non go exceptions would be handled by externally for segfaults. |
|
Hello, I am using following workaround in production for the last couple of years on go1.17+ without known issues. Of course your case may be different. Windows WER/Signal fixWINWERFIX=sed -i -E 's/^(var testingWER bool).*$$/\1 = true/' $(GOROOT)/src/runtime/signal_windows.go (Addendum) |
|
This is really an issue with golang/go I just updated here first, might do a issue on golang/go sometime. |
your workaround realy Inspired me. |
hi!
when i run example code in windows, get this
The text was updated successfully, but these errors were encountered: