Develop Reference

JAVA Simulation error when using Cooja mote in Contiki-ng

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!

JavaFX in Raspberry Pi 4 (Unable to open DISPLAY)

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

JVM crashes with SIGSEGV in JAVA2D Disposer thread

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?

build openjdk9 on macos and crash

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.

Java jmap -heap command gave OutOfMemoryError

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.