search

eclipse-openj9 / openj9

Eclipse OpenJ9: A Java Virtual Machine for OpenJDK that's optimized for small footprint, fast start-up, and high throughput. Builds on Eclipse OMR (https://github.com/eclipse/omr) and combines with the Extensions for OpenJDK for OpenJ9 repo.
Other
3.27k stars 721 forks source link

Unhandled exception Using native Sass compiler #5961

Open phelgren opened 5 years ago

phelgren commented 5 years ago

Java -version output

openjdk version "1.8.0_212" OpenJDK Runtime Environment (build 1.8.0_212-b04) Eclipse OpenJ9 VM (build openj9-0.14.2, JRE 1.8.0 Windows 10 amd64-64-Bit Compressed References 20190521_368 (JIT enabled, AOT enabled) OpenJ9 - 4b1df46fe OMR - b56045d2 JCL - a8c217d402 based on jdk8u212-b04)

Summary of problem

I replaced the Oracle JDK with the OpenJ9 indicated above. I use the Liferay Developer Studio (based on Eclipse) to compile and build modules for deployment. After the JDK change, A Gradle build of a module fails with this error:

Gradle User Home: C:\Users\Pete.BSF_INT.gradle Gradle Distribution: Gradle wrapper from target build Gradle Version: 3.0 Java Home: C:\Program Files\AdoptOpenJDK\jdk-8.0.212.04-openj9 JVM Arguments: None Program Arguments: None Build Scans Enabled: false Offline Mode Enabled: false Gradle Tasks: build

:compileJava UP-TO-DATE :buildCSS Using native Sass compiler Unhandled exception Type=Segmentation error vmState=0x00040000 Windows_ExceptionCode=c0000005 J9Generic_Signal=00000004 ExceptionAddress=00007FF8FBD72F83 ContextFlags=0010005f Handler1=00007FF8FBD6BAB0 Handler2=00007FF91C23CA30 InaccessibleReadAddress=0000000000000010 RDI=0000000002AB9A00 RSI=0000000000000000 RAX=000000000262EA08 RBX=00000000122B74E8 RCX=0000000002AB9A00 RDX=000000000FA94128 R8=0000000000000000 R9=00007FF8FBE41D20 R10=0000000000000001 R11=00007FF8FBE41D20 R12=000000000FA94128 R13=00000000008D5B60 R14=00000000000000B2 R15=0000000000000001 RIP=00007FF8FBD72F83 RSP=000000000262E990 RBP=0000000000000000 GS=002B FS=0053 ES=002B DS=002B XMM0 0000000000000000 (f: 0.000000, d: 0.000000e+000) XMM1 0000000000000000 (f: 0.000000, d: 0.000000e+000) XMM2 0000000000000000 (f: 0.000000, d: 0.000000e+000) XMM3 0000000000000000 (f: 0.000000, d: 0.000000e+000) XMM4 0000000000000000 (f: 0.000000, d: 0.000000e+000) XMM5 0000000000000000 (f: 0.000000, d: 0.000000e+000) XMM6 0000000000000000 (f: 0.000000, d: 0.000000e+000) XMM7 0000000000000000 (f: 0.000000, d: 0.000000e+000) XMM8 0000000000000000 (f: 0.000000, d: 0.000000e+000) XMM9 0000000000000000 (f: 0.000000, d: 0.000000e+000) XMM10 0000000000000000 (f: 0.000000, d: 0.000000e+000) XMM11 0000000000000000 (f: 0.000000, d: 0.000000e+000) XMM12 0000000000000000 (f: 0.000000, d: 0.000000e+000) XMM13 0000000000000000 (f: 0.000000, d: 0.000000e+000) XMM14 0000000000000000 (f: 0.000000, d: 0.000000e+000) XMM15 0000000000000000 (f: 0.000000, d: 0.000000e+000) Module=C:\Program Files\AdoptOpenJDK\jdk-8.0.212.04-openj9\jre\bin\compressedrefs\j9vm29.dll Module_base_address=00007FF8FBCF0000 Offset_in_DLL=0000000000082f83 Target=2_90_20190521_368 (Windows 10 10.0 build 17763) CPU=amd64 (8 logical CPUs) (0x3f8732000 RAM) ----------- Stack Backtrace ----------- (0x00007FF8FBD72F83 [j9vm29+0x82f83]) Java_org_bridj_JNI_bindJavaMethodsToCFunctions+0x255 (0x00007FF913DC68E5 [bridj+0x68e5]) J9_CreateJavaVM+0x8b7c3 (0x00007FF8FBE02773 [j9vm29+0x112773]) J9_CreateJavaVM+0x8b39c (0x00007FF8FBE0234C [j9vm29+0x11234c]) (0x00007FF8FBD05430 [j9vm29+0x15430])

JVMDUMP039I Processing dump event "gpf", detail "" at 2019/05/30 16:29:38 - please wait. JVMDUMP032I JVM requested System dump using 'E:\Workspaces\LR70\ServiceDashboard\core.20190530.162938.10468.0001.dmp' in response to an event JVMDUMP010I System dump written to E:\Workspaces\LR70\ServiceDashboard\core.20190530.162938.10468.0001.dmp JVMDUMP032I JVM requested Java dump using 'E:\Workspaces\LR70\ServiceDashboard\javacore.20190530.162938.10468.0002.txt' in response to an event JVMDUMP010I Java dump written to E:\Workspaces\LR70\ServiceDashboard\javacore.20190530.162938.10468.0002.txt JVMDUMP032I JVM requested Snap dump using 'E:\Workspaces\LR70\ServiceDashboard\Snap.20190530.162938.10468.0003.trc' in response to an event JVMDUMP010I Snap dump written to E:\Workspaces\LR70\ServiceDashboard\Snap.20190530.162938.10468.0003.trc JVMDUMP007I JVM Requesting JIT dump using 'E:\Workspaces\LR70\ServiceDashboard\jitdump.20190530.162938.10468.0004.dmp' JVMDUMP010I JIT dump written to E:\Workspaces\LR70\ServiceDashboard\jitdump.20190530.162938.10468.0004.dmp JVMDUMP013I Processed dump event "gpf", detail "". :buildCSS FAILED

FAILURE: Build failed with an exception.

BUILD FAILED

Total time: 1.927 secs

Diagnostic files

Output files can be found here:

https://drive.google.com/drive/folders/1Eohzx5CgJzHYyFAS_TnGynapHrm0kZon?usp=sharing

DanHeidinga commented 5 years ago

Can you try running with -Xcheck:jni and provide the output here? It can help narrow down whether there is a JNI issue or something else going on.

phelgren commented 5 years ago

Thanks Dan...in preparing the output, I came across some inconsistencies that lead me to a possible solution. In my investigation I came across a notation in the Liferay IDE that may indicate where the problem lies. I found the reference here: https://dev.liferay.com/en/develop/tutorials/-/knowledge_base/7-0/compiling-sass-files-in-a-maven-project

It has this note: "Note: Liferay’s CSS Builder is supported for Oracle’s JDK and uses a native compiler for increased speed. If you’re using an IBM JDK, you may experience issues when building your SASS files (e.g., when building a theme). It’s recommended to switch to using the Oracle JDK, but if you prefer using the IBM JDK, you must use the fallback Ruby compiler."

I don't know what the "issue" is with the IBM JDK, but since OpenJ9 is basically the same JDK, there must be some reported issue. I am going to contact Liferay and see if they can tell me what that issue is. But here are the results of my testing:

I first ran the build after I switched JVM's and all was well:

Working Directory: E:\Workspaces\LR70\ServiceDashboard
Gradle User Home: C:\Users\Pete.BSF_INT\.gradle
Gradle Distribution: Gradle wrapper from target build
Gradle Version: 3.0
Java Home: C:\Program Files\AdoptOpenJDK\jdk-8.0.212.04-openj9
JVM Arguments: -Xcheck:jni
Program Arguments: None
Build Scans Enabled: false
Offline Mode Enabled: false
Gradle Tasks: deploy

:compileJava UP-TO-DATE
:buildCSS
Using native Sass compiler
:processResources UP-TO-DATE
:transpileJS SKIPPED
:configJSModules SKIPPED
:replaceSoyTranslation UP-TO-DATE
:wrapSoyAlloyTemplate SKIPPED
:classes UP-TO-DATE
:jar
:deploy UP-TO-DATE

BUILD SUCCESSFUL

Total time: 21.669

You can see that the native SASS compiler actually isn't invoked because the artifact was up to date. I then ran a "clean":

Working Directory: E:\Workspaces\LR70\ServiceDashboard
Gradle User Home: C:\Users\Pete.BSF_INT\.gradle
Gradle Distribution: Gradle wrapper from target build
Gradle Version: 3.0
Java Home: C:\Program Files\AdoptOpenJDK\jdk-8.0.212.04-openj9
JVM Arguments: None
Program Arguments: None
Build Scans Enabled: false
Offline Mode Enabled: false
Gradle Tasks: clean

:cleanBuildCSS
:cleanCompileJSP
:cleanCompileJava
:cleanCompileTestIntegrationJava UP-TO-DATE
:cleanCompileTestJava UP-TO-DATE
:cleanCopyTLDDocResources UP-TO-DATE
:cleanDownloadNode UP-TO-DATE
:cleanGenerateJSPJava UP-TO-DATE
:cleanJar
:cleanJavadoc UP-TO-DATE
:cleanProcessResources
:cleanProcessTestIntegrationResources UP-TO-DATE
:cleanProcessTestResources UP-TO-DATE
:cleanTest UP-TO-DATE
:cleanTestIntegration UP-TO-DATE
:cleanTlddoc UP-TO-DATE
:cleanTranspileJS UP-TO-DATE
:clean

BUILD SUCCESSFUL

Total time: 0.26 secs

And then I ran the build again and THEN it failed:

Working Directory: E:\Workspaces\LR70\ServiceDashboard
Gradle User Home: C:\Users\Pete.BSF_INT\.gradle
Gradle Distribution: Gradle wrapper from target build
Gradle Version: 3.0
Java Home: C:\Program Files\AdoptOpenJDK\jdk-8.0.212.04-openj9
JVM Arguments: -Xcheck:jni
Program Arguments: None
Build Scans Enabled: false
Offline Mode Enabled: false
Gradle Tasks: build

:compileJava
:buildCSS
Using native Sass compiler
Unhandled exception
Type=Segmentation error vmState=0x00040000
Windows_ExceptionCode=c0000005 J9Generic_Signal=00000004 ExceptionAddress=00007FFC83C52F83 ContextFlags=0010005f
Handler1=00007FFC83C4BAB0 Handler2=00007FFC83F2CA30 InaccessibleReadAddress=0000000000000010
RDI=00000000032B9A00 RSI=0000000000000000 RAX=0000000002E2E9F8 RBX=00000000126D73A8
RCX=00000000032B9A00 RDX=00000000115E70A8 R8=0000000000000000 R9=00007FFC83D21D20
R10=0000000000000001 R11=00007FFC83D21D20 R12=00000000115E70A8 R13=0000000000F92E90
R14=00000000000000B2 R15=0000000000000001
RIP=00007FFC83C52F83 RSP=0000000002E2E980 RBP=0000000000000000 GS=002B
FS=0053 ES=002B DS=002B
XMM0 0000000000000000 (f: 0.000000, d: 0.000000e+000)
XMM1 0000000000000000 (f: 0.000000, d: 0.000000e+000)
XMM2 0000000000000000 (f: 0.000000, d: 0.000000e+000)
XMM3 0000000000000000 (f: 0.000000, d: 0.000000e+000)
XMM4 0000000000000000 (f: 0.000000, d: 0.000000e+000)
XMM5 0000000000000000 (f: 0.000000, d: 0.000000e+000)
XMM6 0000000000000000 (f: 0.000000, d: 0.000000e+000)
XMM7 0000000000000000 (f: 0.000000, d: 0.000000e+000)
XMM8 0000000000000000 (f: 0.000000, d: 0.000000e+000)
XMM9 0000000000000000 (f: 0.000000, d: 0.000000e+000)
XMM10 0000000000000000 (f: 0.000000, d: 0.000000e+000)
XMM11 0000000000000000 (f: 0.000000, d: 0.000000e+000)
XMM12 0000000000000000 (f: 0.000000, d: 0.000000e+000)
XMM13 0000000000000000 (f: 0.000000, d: 0.000000e+000)
XMM14 0000000000000000 (f: 0.000000, d: 0.000000e+000)
XMM15 0000000000000000 (f: 0.000000, d: 0.000000e+000)
Module=C:\Program Files\AdoptOpenJDK\jdk-8.0.212.04-openj9\jre\bin\compressedrefs\j9vm29.dll
Module_base_address=00007FFC83BD0000 Offset_in_DLL=0000000000082f83
Target=2_90_20190521_368 (Windows 10 10.0 build 17763)
CPU=amd64 (8 logical CPUs) (0x3f8732000 RAM)
----------- Stack Backtrace -----------
(0x00007FFC83C52F83 [j9vm29+0x82f83])
Java_org_bridj_JNI_bindJavaMethodsToCFunctions+0x255 (0x00007FFCD6EE68E5 [bridj+0x68e5])
J9_CreateJavaVM+0x8b7c3 (0x00007FFC83CE2773 [j9vm29+0x112773])
J9_CreateJavaVM+0x8b39c (0x00007FFC83CE234C [j9vm29+0x11234c])
(0x00007FFC83BE5430 [j9vm29+0x15430])
---------------------------------------
JVMDUMP039I Processing dump event "gpf", detail "" at 2019/05/31 11:43:44 - please wait.
JVMDUMP032I JVM requested System dump using 'E:\Workspaces\LR70\ServiceDashboard\core.20190531.114344.1980.0001.dmp' in response to an event
JVMDUMP010I System dump written to E:\Workspaces\LR70\ServiceDashboard\core.20190531.114344.1980.0001.dmp
JVMDUMP032I JVM requested Java dump using 'E:\Workspaces\LR70\ServiceDashboard\javacore.20190531.114344.1980.0002.txt' in response to an event
JVMDUMP010I Java dump written to E:\Workspaces\LR70\ServiceDashboard\javacore.20190531.114344.1980.0002.txt
JVMDUMP032I JVM requested Snap dump using 'E:\Workspaces\LR70\ServiceDashboard\Snap.20190531.114344.1980.0003.trc' in response to an event
JVMDUMP010I Snap dump written to E:\Workspaces\LR70\ServiceDashboard\Snap.20190531.114344.1980.0003.trc
JVMDUMP007I JVM Requesting JIT dump using 'E:\Workspaces\LR70\ServiceDashboard\jitdump.20190531.114344.1980.0004.dmp'
JVMDUMP010I JIT dump written to E:\Workspaces\LR70\ServiceDashboard\jitdump.20190531.114344.1980.0004.dmp
JVMDUMP013I Processed dump event "gpf", detail "".
:buildCSS FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':buildCSS'.
> Process 'command 'C:\Program Files\AdoptOpenJDK\jdk-8.0.212.04-openj9\bin\java.exe'' finished with non-zero exit value -1

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

Total time: 4.429 secs

I don't know what the issue is with the J9 JVM and the SASS compiler, I will contact Liferay. There is a workaround which is to use the Ruby compiler as an alternative for SASS compiles but I am curious as to why the Liferay team didn't pursue a fix to the J9 JVM "issue", whatever it was.

We can either close this because the issue is "known" (at least by the Liferay team) OR I'll be happy to keep running this down with you if you want.

pshipton commented 5 years ago

Added to the 0.15 milestone as a reminder to keep an eye on this.

pshipton commented 5 years ago

I don't expect this will be resolved in the 0.15 release, moving forward.

@phelgren is there any update from Liferay?

DanHeidinga commented 5 years ago

The source for the crashing method is https://github.com/nativelibs4java/BridJ/blob/373c03447df44b5a5508e94fa897369b41b18f48/src/main/cpp/bridj/JNI.c#L989

Coupled with InaccessibleReadAddress=0000000000000010 I suspect this is attempting to read from NULL.

phelgren commented 5 years ago

I have not heard anything from the Liferay team as yet.  There is another J9 issue with using Liferay's implementation of JSONSerializer that produces no output and no stacktrace.  I don't know if there is a general issue with JSON serialization (I haven't tried it with FlexJSON for instance) but I'll need to chase it down as well although switching between JDK's is a hassle.  I don't know to what extent all artifacts need to be recompiled when switching JDK's.

Other than the SASS issue and the JSON Serialization issue, I have been happy with the performance and compatibility of the J9 JDK.

Pete Helgren www.petesworkshop.com GIAC Secure Software Programmer-Java Twitter - Sys_i_Geek IBM_i_Geek

On 6/21/2019 3:57 PM, Peter Shipton wrote:

I don't expect this will be resolved in the 0.15 release, moving forward.

@phelgren https://github.com/phelgren is there any update from Liferay?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/eclipse/openj9/issues/5961?email_source=notifications&email_token=AAAWBDJKZ5WCUXFIMUHHCYTP3U6CHA5CNFSM4HRMHDJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYJSEAY#issuecomment-504570371, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAWBDO6TBCFIM66ZHHOW7LP3U6CHANCNFSM4HRMHDJQ.

Condor70 commented 4 years ago

Just ran into this issue myself.

I created a new project based on the com.liferay.project.templates.spring.mvc.portlet-1.0.53 archetype and it crashed my Eclipse instance (IBM RAD).

This was caused by com.liferay.css.builder:3.0.0:build in combination with the IBM J9 JVM. I tried multiple JVMs and Oracle en OpenJDK Hotspot both work, but IBM J9 and OpenJDK J9 both fail with the segmentation error mentioned above.

pshipton commented 4 years ago

I don't see any solution being worked on for the 0.17 release, moving to the next.