I was having problems configuring my Raspberry Pi 4, as I explained in my previous question (JavaFX in RaspberryPi 4 with Liberica (Cannot open display ,Cannot create resource)), so I decided to start over.
I followed the steps on the Gluon tutorial (https://docs.gluonhq.com/#_javafx_on_embedded), (thanks to #José Pereda) but in the end, when I have to execute the line:
sudo -E java -Dglass.platform=gtk --module-path /opt/javafx-sdk-17/lib --add-modules javafx.controls -cp dist/. hellofx.HelloFX
It shows me this error:
Exception in thread "main" java.lang.reflect.InvocationTargetException
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:1051)
Caused by: java.lang.UnsupportedOperationException: Unable to open DISPLAY
at javafx.graphics/com.sun.glass.ui.gtk.GtkApplication.lambda$new$6(GtkApplication.java:173)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at javafx.graphics/com.sun.glass.ui.gtk.GtkApplication.<init>(GtkApplication.java:171)
at javafx.graphics/com.sun.glass.ui.gtk.GtkPlatformFactory.createApplication(GtkPlatformFactory.java:41)
at javafx.graphics/com.sun.glass.ui.Application.run(Application.java:145)
at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.startup(QuantumToolkit.java:281)
at javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:288)
at javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:160)
at javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658)
at javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409)
at javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363)
... 5 more
I have activated X11Forwarding in /etc/ssh/sshd_config.
I remember this error from other Attempts to work with JavaFX, so I tried to change from -Dglass.platform=gtk to -Dglass.platform=Monocle, but then It shows this fail:
Exception in thread "Event Thread" java.lang.UnsatisfiedLinkError: 'void com.sun.glass.ui.monocle.DispmanScreen.wrapNativeSymbols()'
at javafx.graphics/com.sun.glass.ui.monocle.DispmanScreen.wrapNativeSymbols(Native Method)
at javafx.graphics/com.sun.glass.ui.monocle.DispmanScreen.<init>(DispmanScreen.java:34)
at javafx.graphics/com.sun.glass.ui.monocle.DispmanPlatform.createScreen(DispmanPlatform.java:38)
at javafx.graphics/com.sun.glass.ui.monocle.NativePlatform.getScreen(NativePlatform.java:129)
at javafx.graphics/com.sun.glass.ui.monocle.MonocleApplication.staticScreen_getScreens(MonocleApplication.java:222)
at javafx.graphics/com.sun.glass.ui.Screen.initScreens(Screen.java:412)
at javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Application.java:153)
at javafx.graphics/com.sun.glass.ui.monocle.RunnableProcessor.runLoop(RunnableProcessor.java:92)
at javafx.graphics/com.sun.glass.ui.monocle.RunnableProcessor.run(RunnableProcessor.java:51)
at java.base/java.lang.Thread.run(Thread.java:834)
I'm using a 5.0 inch screen (http://www.lcdwiki.com/5inch_HDMI_Display-B) with an adapter from hdmi to microhdmi.
After Comments things
Enabling X11 Forwarding,same errors trying with sudo -E java -Dglass.platform=gtk --module-path /opt/javafx-sdk-17/lib --add-modules javafx.controls export DISPLAY='IP:0.0' -cp dist/. hellofx.HelloFX
then trying with:
sudo -E java -Degl.displayid=/dev/dri/card1 -Dembedded=monocle -Dglass.platform=Monocle -Dmonocle.platform=EGL -Dmonocle.egl.lib=/opt/javafx-sdk-17/lib/libgluon_drm-1.1.0.so -Dprism.verbose=true --module-path /opt/javafx-sdk-17/lib --add-modules javafx.controls -cp dist/. hellofx.HelloFX
I get:
Prism pipeline init order: es2 sw
Using Double Precision Marlin Rasterizer
Using dirty region optimizations
Using system sized mask for primitives
Not forcing power of 2 sizes for textures
Using hardware CLAMP_TO_ZERO mode
Opting in for HiDPI pixel scaling
Prism pipeline name = com.sun.prism.es2.ES2Pipeline
Loading ES2 native library ... prism_es2_monocle
succeeded.
GLFactory using com.sun.prism.es2.MonocleGLFactory
[GluonDRM] use GPU at /dev/dri/card1 and display id -1
S0 NOT defined:
[GluonDRM] Device /dev/dri/card1 could be opened, but has no drm capabilities.eglinit failed
eglbind ok
eglCreateWindowSurface called
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0xb6dbd830, pid=904, tid=921
#
# JRE version: OpenJDK Runtime Environment (11.0.9.1+1) (build 11.0.9.1+1-post-Raspbian-1deb10u2)
# Java VM: OpenJDK Server VM (11.0.9.1+1-post-Raspbian-1deb10u2, mixed mode, g1 gc, linux-)
# Problematic frame:
# C [libc.so.6+0x77830] strlen+0x0
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /home/pi/Downloads/samples/CommandLine/Modular/CLI/hellofx/hs_err_pid904.log
#
# If you would like to submit a bug report, please visit:
# Unknown
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Abortado
I used ulimit -c unlimited, then used same command, getting:
Prism pipeline init order: es2 sw
Using Double Precision Marlin Rasterizer
Using dirty region optimizations
Using system sized mask for primitives
Not forcing power of 2 sizes for textures
Using hardware CLAMP_TO_ZERO mode
Opting in for HiDPI pixel scaling
Prism pipeline name = com.sun.prism.es2.ES2Pipeline
Loading ES2 native library ... prism_es2_monocle
succeeded.
GLFactory using com.sun.prism.es2.MonocleGLFactory
[GluonDRM] use GPU at /dev/dri/card1 and display id -1
S0 NOT defined:
[GluonDRM] Device /dev/dri/card1 could be opened, but has no drm capabilities.eglinit failed
eglbind ok
eglCreateWindowSurface called
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0xb6dcc830, pid=923, tid=940
#
# JRE version: OpenJDK Runtime Environment (11.0.9.1+1) (build 11.0.9.1+1-post-Raspbian-1deb10u2)
# Java VM: OpenJDK Server VM (11.0.9.1+1-post-Raspbian-1deb10u2, mixed mode, g1 gc, linux-)
# Problematic frame:
# C [libc.so.6+0x77830] strlen+0x0
#
# Core dump will be written. Default location: /home/pi/Downloads/samples/CommandLine/Modular/CLI/hellofx/core
#
# An error report file with more information is saved as:
# /home/pi/Downloads/samples/CommandLine/Modular/CLI/hellofx/hs_err_pid923.log
#
# If you would like to submit a bug report, please visit:
# Unknown
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Abortado
Related
I'm trying to do a simulation in Cooja simulator, Contiki-ng using cooja motes and CSMA and the energest model.
Even though the simulation works well in Z1 mote with cooja motes the simulation stops and I get a null pointer error:
[15:19:20 - Thread-1] [Simulation.java:308] [FATAL] - Simulation stopped due to error: null
java.lang.NullPointerException: null
at org.contikios.cooja.contikimote.ContikiMoteType.getCoreMemory(ContikiMoteType.java:824) ~[cooja.jar:?]
at org.contikios.cooja.contikimote.ContikiMote.execute(ContikiMote.java:149) ~[cooja.jar:?]
at org.contikios.cooja.motes.AbstractWakeupMote$1.execute(AbstractWakeupMote.java:51) ~[cooja.jar:?]
at org.contikios.cooja.Simulation.run(Simulation.java:296) ~[cooja.jar:?]
at java.lang.Thread.run(Thread.java:829) ~[?:?]
When I try to do the same simulation with TSCH, 6TiSCH 6top and add the energest model I get this error:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f893449310d, pid=723817, tid=724266
#
# JRE version: OpenJDK Runtime Environment 18.9 (11.0.15+10) (build 11.0.15+10-LTS)
# Java VM: OpenJDK 64-Bit Server VM 18.9 (11.0.15+10-LTS, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# V [libjvm.so+0xa5710d] Klass::search_secondary_supers(Klass*) const+0xd
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %e" (or dumping to usr/contiki-ng/tools/cooja/build/core.723817)
#
# If you would like to submit a bug report, please visit:
# https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%208&component=java-11-openjdk
a quick search says it's a bug, but as it only occurs when I add the energy model I'm not sure!
Problem
After update my macOS to Monterrey (12.0.1), I'm with a big problem to start my local projects with ExtJS.
When I execute:
sencha app watch
Get the error:
Sencha Cmd v7.5.0.5
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007ff813dcb6f2, pid=18621, tid=0x000000000000a707
#
# JRE version: OpenJDK Runtime Environment (8.0_242-b08) (build 1.8.0_242-b08)
# Java VM: OpenJDK 64-Bit Server VM (25.242-b08 mixed mode bsd-amd64 compressed oops)
# Problematic frame:
# C [libsystem_platform.dylib+0x16f2] _platform_strlen+0x12
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# [my app folder]/hs_err_pid18621.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
/Users/kellerkichel/bin/Sencha/Cmd/sencha: line 167: 18621 Abort trap: 6 $BASEDIR/$VER/sencha "$#"
The funny thing is... if run again... the same command (sencha app watch), the error change:
2021-12-06 22:10:28.229 java[17909:173895] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[NSPlaceholderString initWithFormat:locale:arguments:]: nil argument'
*** First throw call stack:
(
0 CoreFoundation 0x00007ff813efae5b __exceptionPreprocess + 242
1 libobjc.A.dylib 0x00007ff813c5bb9d objc_exception_throw + 48
2 Foundation 0x00007ff814c9126d -[NSPlaceholderString initWithFormat:locale:arguments:] + 295
3 Foundation 0x00007ff814c9ff2f +[NSString stringWithFormat:] + 153
4 Update1478821341979869630.dylib 0x00000001218897a9 wuusgJAD + 553
5 Update1478821341979869630.dylib 0x0000000121874319 pGgFelzv + 9
6 Update1478821341979869630.dylib 0x0000000121888ab2 MKNXgAzM + 562
7 Update1478821341979869630.dylib 0x000000012188795d tyRtaPXr + 61
8 Update1478821341979869630.dylib 0x00000001218877bb ZWwnJFGw + 283
9 Update1478821341979869630.dylib 0x0000000121880dc6 Phdl_SDOTFG + 246
10 Update1478821341979869630.dylib 0x0000000121880e49 Phdl_SDOTF + 25
11 Update1478821341979869630.dylib 0x000000012186e505 Java_phdl_Phdl_SDOTF + 21
12 ??? 0x000000010e0e3407 0x0 + 4530779143
)
libc++abi: terminating with uncaught exception of type NSException
/Users/kellerkichel/bin/Sencha/Cmd/sencha: line 167: 17909 Abort trap: 6 $BASEDIR/$VER/sencha "$#"
And again (sencha app watch)... another one:
java(18084,0x7000041c5000) malloc: Heap corruption detected, free list is damaged at 0x6000005f3330
*** Incorrect guard value: 105553126503408
java(18084,0x7000041c5000) malloc: *** set a breakpoint in malloc_error_break to debug
/Users/kellerkichel/bin/Sencha/Cmd/sencha: line 167: 18084 Abort trap: 6 $BASEDIR/$VER/sencha "$#"
And after each execution, the error keep alternating between those above...
Attempts
1 - JAVA
First, I thinked is something with JAVA version, so I removed all JAVA installed, including brew installed versions.
Also removed all references to JAVA_HOME, and a fresh install of JAVA 8 was maked. No sucess... did it again with JAVA 11, and JAVA 17, without sucess.
Obs. At JAVA 17 the problem changed, but this is because JAVA 17 dont have the javascript processor (javax) anymore.
2 - SENCHA CMD
After the JAVA, have checked Sencha cmd, if has any update or something... my Sencha cmd versio is 7.4.0.39, and for my surprise have a new version (7.5.0.5), but also after update still not working.
Any sugestions?
After talking with some sencha MVP at discord.... have received the following tip:
You must delete the following file:
/Users/user/Library/Application Support/Sencha/Cmd/Update/app.properties
After that workaround, the system works again.
I hope these answer can help someone !!
Update!!!
After some mac os updates deleting the app.properties stop working.
So sencha report to add bypass_lp:true to the app.json
Download JRE 8(support apple sillicon neccessary, ex:zulu/bellsoft), and unzip it.
Edit path in "{your_senchacmd_path}/.install4j/inst_jre.cfg" and "{your_senchacmd_path}/.install4j/pref_jre.cfg" to new JRE path.
Reason: Sencha CMD's included JRE is not compiled for the ARM architecture and even with Rosetta 2.
I got a JVM crash on a production server. It generated a log in /tmp/jvm-32627/hs_error.log. The beginning of the file is:
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f4cdd7fba55, pid=32627, tid=139964606174976
#
# JRE version: OpenJDK Runtime Environment (7.0_79-b14) (build 1.7.0_79-mockbuild_2015_07_24_09_26-b00)
# Java VM: OpenJDK 64-Bit Server VM (24.79-b02 mixed mode linux-amd64 compressed oops)
# Derivative: IcedTea 2.5.5
# Distribution: CentOS release 6.6 (Final), package rhel-2.5.5.4.el6-x86_64 u79-b14
# Problematic frame:
# V [libjvm.so+0x610a55]
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please include
# instructions on how to reproduce the bug and visit:
# http://icedtea.classpath.org/bugzilla
#
--------------- T H R E A D ---------------
Current thread (0x00007f4b1b90c000): JavaThread "Java2D Disposer" daemon [_thread_in_vm, id=33107, stack(0x00007f4c0c91d000,0x00007f4c0ca1e000)]
siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x0000000000000000
Registers:
RAX=0x0000000000000000, RBX=0x00007f4b1b90c000, RCX=0x00007f4c0ca1c480, RDX=0x00007f4cddfe11a0
RSP=0x00007f4c0ca1c450, RBP=0x00007f4c0ca1c4e0, RSI=0x00007f4b1b90c000, RDI=0x00007f4c0ca1c480
R8 =0x00007f4c0ca1c490, R9 =0x0000000000000000, R10=0x00007f4cddfd7ef8, R11=0x0000000000000002
R12=0x00007f4b1b90c1d8, R13=0x00007f4b6c12d850, R14=0x00000000000000c2, R15=0x0000000000000000
RIP=0x00007f4cdd7fba55, EFLAGS=0x0000000000010246, CSGSFS=0x0000000000000033, ERR=0x0000000000000004
TRAPNO=0x000000000000000e
Top of Stack: (sp=0x00007f4c0ca1c450)
0x00007f4c0ca1c450: 00007f4b1b90c000 00007f4c001c3758
0x00007f4c0ca1c460: 00007f4c0ca1c470 00000000000000c2
0x00007f4c0ca1c470: 00007f4b1b90c000 00007f4c0ca1c480
0x00007f4c0ca1c480: 00007f4b1b90c000 0000000000000000
0x00007f4c0ca1c490: 0000000000000004 00007f4c001c37a8
0x00007f4c0ca1c4a0: 00007f4b1b90c000 523beb0a00000001
0x00007f4c0ca1c4b0: 00007f4b6c12d850 00007f4b1b90c1d8
0x00007f4c0ca1c4c0: 00007f4b6c0bc320 00007f4b6c12d850
0x00007f4c0ca1c4d0: 00007f4b6c054f40 00007f4b1b90c000
0x00007f4c0ca1c4e0: 00007f4c0ca1c500 00007f4c0c0cbe31
0x00007f4c0ca1c4f0: 00007f4b6c12d930 0000000000000001
0x00007f4c0ca1c500: 00007f4b6c12d6a0 000000358b610f17
0x00007f4c0ca1c510: 00007f4b6c04fc90 00007f4b6c12d6a0
0x00007f4c0ca1c520: 000000358b89b6e0 000000358b6119d4
0x00007f4c0ca1c530: 00007f4b6c12d6a0 00007f4b6c04fc90
(The stack goes on for 2000 more lines or so...)
The JVM is a IcedTea 2 compilation (OpenJDK 1.7.0_79), was executing a Tomcat 7 and is running on a CentOS 6.6 (Linux 2.6.32-573.el6.x86_64 kernel).
After some research, it seems the Java2D Disposer thread is a thread used to free native resources used by Java2D and AWT and which are not managed by the GC. I can't see why it is sollicitated by a JavaEE server...
We had that crash last night, but investigations showed it probably happened a first time in October 2017 and a second time in March 2018. One crash in 6 or 8 months could be considered acceptable, but that system is business critical (even if really flawed by so many bugs, bad smelling code, old versions of libraries and tools, and so on...) and I really would like to get rid of the problem.
Normally, we should have a core-dump, but core-dump has been of course disabled, so we have nothing.
Does anyone know what is happening and how to solve it?
I encountered these problems when I building openjdk9.
os: macos high sierra(10.13.5)
xcode： 9.4
freetype: 2.9.1
I encountered these problems when I building openjdk9
Building target 'default (exploded-image)' in configuration 'macosx-
x86_64-normal-server-slowdebug'
Warning: No mercurial configuration present and no .src-rev
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGILL (0x4) at pc=0x000000010394aca8, pid=13189, tid=8451
#
# JRE version: OpenJDK Runtime Environment (9.0.4) (slowdebug build
9.0.4-internal+0-adhoc.apple.jdk9u)
# Java VM: OpenJDK 64-Bit Server VM (slowdebug 9.0.4-internal+0-adhoc.apple.jdk9u, mixed mode, tiered, compressed oops, serial gc, bsd-amd64)
# Problematic frame:
# V [libjvm.dylib+0xd4aca8] PerfData::~PerfData()+0x8
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /Users/apple/SourceCode/jdk9u/make/hs_err_pid13189.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
#
[error occurred during error reporting (), id 0x4]
make[3]: *** [/Users/apple/SourceCode/jdk9u/build/macosx-x86_64-normal-server-slowdebug/jdk/_packages_attribute.done] Abort trap: 6
make[2]: *** [exploded-image-optimize] Error 2
ERROR: Build failed for target 'default (exploded-image)' in configuration 'macosx-x86_64-normal-server-slowdebug' (exit code 2)
No indication of failed target found.
Hint: Try searching the build log for '] Error'.
Hint: See common/doc/building.html#troubleshooting for assistance.
make[1]: *** [main] Error 2
make: *** [default] Error
I try to set slowdebug and fastdebug, always failure.
We are periodically runnign jmap -heap command to monitor a tomcat application. However this is first time when we got OutOfMemoryError.
When we monitor the memory at server level there is around 110MB available. Since it is just monitoring can we ignore this time assuming no harm has been done to the application and the server was low on memory when this command run?
$ ./jmap -heap 13511
Attaching to process ID 13511, please wait...
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at sun.tools.jmap.JMap.runTool(JMap.java:179)
at sun.tools.jmap.JMap.main(JMap.java:110)
Caused by: java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:597)
at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.<init>(LinuxDebuggerLocal.java:210)
at sun.jvm.hotspot.bugspot.BugSpotAgent.setupDebuggerLinux(BugSpotAgent.java:816)
at sun.jvm.hotspot.bugspot.BugSpotAgent.setupDebugger(BugSpotAgent.java:518)
at sun.jvm.hotspot.bugspot.BugSpotAgent.go(BugSpotAgent.java:493)
at sun.jvm.hotspot.bugspot.BugSpotAgent.attach(BugSpotAgent.java:332)
at sun.jvm.hotspot.tools.Tool.start(Tool.java:163)
at sun.jvm.hotspot.tools.HeapSummary.main(HeapSummary.java:39)
UPDATE: We tried to run jmap -heap again and got java.lang.OutOfMemoryError: Cannot create GC thread. Out of system resources.
So, the problem seems to be at OS resource level.
$ ./jmap -heap 13511
#
# A fatal error has been detected by the Java Runtime Environment:
#
# java.lang.OutOfMemoryError: Cannot create GC thread. Out of system resources.
#
# Internal Error (gcTaskThread.cpp:38), pid=13162, tid=1104300352
# Error: Cannot create GC thread. Out of system resources.
#
# JRE version: 6.0_18-b07
# Java VM: Java HotSpot(TM) 64-Bit Server VM (16.0-b13 mixed mode linux-amd64 )
# An error report file with more information is saved as:
# /data01/home/s618199/JAVA/jdk1.6.0_18/bin/hs_err_pid13162.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#
Aborted
This is not a memory problem (even though it is reported as one) but an operating system resource problem: You can not create any more threads. And it seems to affect the jmap program and not Tomcat.