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!

Sencha CMD problem after macOS Monterrey update

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.

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

Java VM: Java HotSpot(TM) 64-Bit Server VM (24.60-b09 mixed mode linux-amd64 compressed oops)

I just want to
run ORACLE SQL Developer 4.0.2.12.21
in OpenSuSE 13.11.10 - 64x
linux-l4i7:/home/suse/bin/sqldeveloper # ./sqldeveloper.sh
> Oracle SQL Developer
> Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights reserved.
>
>
>
> LOAD TIME : 448#
># A fatal error has been detected by the Java Runtime Environment:
>
># SIGSEGV (0xb) at pc=0x00007f084ebe7250, pid=20064, tid=139674518972160
>#
># JRE version: Java(TM) SE Runtime Environment (7.0_60-b19) (build 1.7.0_60-b19)
># Java VM: Java HotSpot(TM) 64-Bit Server VM (24.60-b09 mixed mode linux-amd64 compressed >oops)
># Problematic frame:
># C 0x00007f084ebe7250
>#
># 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:
># /home/suse/bin/sqldeveloper/sqldeveloper/bin/hs_err_pid20064.log
>#
># If you would like to submit a bug report, please visit:
># http://bugreport.sun.com/bugreport/crash.jsp
>#
>/home/suse/bin/sqldeveloper/sqldeveloper/bin/../../ide/bin/launcher.sh: line 1193: 20064 >Aborted ${JAVA} "${APP_VM_OPTS[#]}" ${APP_ENV_VARS} -classpath >${APP_CLASSPATH} ${APP_MAIN_CLASS} "${APP_APP_OPTS[#]}"
--------------- T H R E A D ---------------
Current thread is native thread
siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x00007f084ebe7250
Registers:
RAX=0x0000000000000001, RBX=0x00007f0882166a38, RCX=0x00007f0882166700, RDX=0x00007f084ebe7250
RSP=0x00007f0882165f18, RBP=0x00007f08ba697308, RSI=0x0000000000000001, RDI=0x00007f0865061140
R8 =0x00007f08b42af7f0, R9 =0x0000000000000001, R10=0x0000000000000000, R11=0x0000000000000246
R12=0x0000000000000000, R13=0x00007f08ba6972e8, R14=0x0000000000000004, R15=0x000000000000001e
RIP=0x00007f084ebe7250, EFLAGS=0x0000000000010206, CSGSFS=0x0000000000000033, ERR=0x0000000000000014
TRAPNO=0x000000000000000e
Top of Stack: (sp=0x00007f0882165f18)
0x00007f0882165f18: 00007f08ba485e92 00007f0882166700
0x00007f0882165f28: 00007f0882166700 0000000000000000
0x00007f0882165f38: 0000000000000000 00007f08ba8bc000
0x00007f0882165f48: 00007f08ba891df0 00007f0882166700
Instructions: (pc=0x00007f084ebe7250)
0x00007f084ebe7230:
[error occurred during error reporting (printing registers, top of stack, instructions near pc), id 0xb]
Register to memory mapping:
RAX=0x0000000000000001 is an unknown value
RBX=0x00007f0882166a38 is an unknown value
RCX=0x00007f0882166700 is an unknown value
RDX=0x00007f084ebe7250 is an unknown value
Card table byte_map: [0x00007f08b8010000,0x00007f08b8221000] byte_map_base: 0x00007f08b7a20000
Polling page: 0x00007f08ba8b9000
Code Cache [0x00007f08b1000000, 0x00007f08b1470000, 0x00007f08b4000000)
total_blobs=1875 nmethods=1189 adapters=639 free_code_cache=44718Kb largest_free_block=45718336
Compilation events (10 events):
Event: 13.402 Thread 0x00007f08b409f000 nmethod 1371 0x00007f08b1421390 code [0x00007f08b14214c0, 0x00007f08b1421538]
Event: 13.402 Thread 0x00007f08b409f000 1372 java.util.Date::getTime (5 bytes)
Event: 13.402 Thread 0x00007f08b409f000 nmethod 1372 0x00007f08b1421150 code [0x00007f08b1421280, 0x00007f08b14212f8]
Event: 13.403 Thread 0x00007f08b409f000 1373 org.openide.util.NbCollections$4$1::hasNext (13 bytes)
Event: 13.403 Thread 0x00007f08b409f000 nmethod 1373 0x00007f08b1406f50 code [0x00007f08b14070a0, 0x00007f08b1407178]
Event: 13.404 Thread 0x00007f08b409f000 1374 javax.ide.extension.spi.DefaultElementContext::getVisitorForStartElementImpl (243 bytes)
Event: 13.542 Thread 0x00007f08b409f000 nmethod 1374 0x00007f08b1454e50 code [0x00007f08b1455180, 0x00007f08b1456b40]
Event: 13.542 Thread 0x00007f08b409f000 1375 oracle.javatools.data.ChangeBuffer::addChangeInfo (10 bytes)
Event: 13.546 Thread 0x00007f08b409f000 nmethod 1375 0x00007f08b1343710 code [0x00007f08b1343880, 0x00007f08b1343ba8]
Event: 13.546 Thread 0x00007f08b409f000 1376 oracle.javatools.data.ChangeInfo::<init> (85 bytes)

This is a native Java crash. It can be a Bug in the JVM, the netbeans launcher, maybe some incompatibilities in your environment (especially wrong or missing libraries).
Did this sqldeveloper installation include a JRE? You might want to change the script to point to a system JVM. The hs_err file looks a bit incomplete. It should for example contain a list of loaded libraries and the path of the actual Java binary. Did you cut that out or is it missing?

Might not be related but this worked for me
gksudo gedit /usr/bin/sqldeveloper
Then these 2 lines at the top:
unset GNOME_DESKTOP_SESSION_ID
unset DBUS_SESSION_BUS_ADDRESS
Found the answer here
http://linuxsagas.digitaleagle.net/2014/01/28/fixing-sql-developer-4-0/

java.lang.OutOfMemoryError: requested 1958536 bytes for Chunk::new. Out of swap space

We are facing the below problem at our production enviournment in unpredictable manner
sometimes the server is down in a day or sometimes in a week, below is the exact error
dump, below are the settings for the server.
JDK: jdk1.6.0_21
Server: Tomcat 7.0.2
OS: Red Hat Enterprise Linux Server release 5.5
In catalina.sh the following setting has been done:
JAVA_OPTS="-Xms1024M -Xmx1536M -XX:+HeapDumpOnOutOfMemoryError -XX:+AggressiveOpts
-XX:-DisableExplicitGC -XX:AdaptiveSizeThroughPutPolicy=0
-XX:+UsePSAdaptiveSurvivorSizePolicy
-XX:+UseAdaptiveGenerationSizePolicyAtMinorCollection
-XX:+UseAdaptiveGenerationSizePolicyAtMajorCollection -XX:PermSize=768M
-XX:MaxPermSize=768M -XX:+PrintGCDetails -Xloggc:/tmp/gcLogs.txt"
export CATALINA_OPTS="-Dcom.sun.management.jmxremote.port=22222
-Dcom.sun.management.jmxremote.authenticate=true -Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.password.file=/jakarta-tomcat7/apache-tomcat-7.0.2/conf
/jmxremote.password -Dcom.sun.management.jmxremote.access.file=/jakarta-tomcat7/apache-
tomcat-7.0.2/conf/jmxremote.access"
Error Trace:-
#
# A fatal error has been detected by the Java Runtime Environment:
#
# java.lang.OutOfMemoryError: requested 1958536 bytes for Chunk::new. Out of swap space?
#
# Internal Error (allocation.cpp:215), pid=18658, tid=589781904
# Error: Chunk::new
#
# JRE version: 6.0_21-b06
# Java VM: Java HotSpot(TM) Server VM (17.0-b16 mixed mode linux-x86 )
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#
--------------- T H R E A D ---------------
Current thread (0x23787400): JavaThread "CompilerThread0" daemon [_thread_in_native, id=18668, stack(0x231f5000,0x23276000)]
Stack: [0x231f5000,0x23276000], sp=0x23272e70, free space=1f723276000k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x6a9262]
V [libjvm.so+0x2b277f]
V [libjvm.so+0x12e03c]
V [libjvm.so+0x12e536]
V [libjvm.so+0x5d67d0]
V [libjvm.so+0x2f809d]
V [libjvm.so+0x4f65a9]
V [libjvm.so+0x27b85f]
V [libjvm.so+0x278043]
V [libjvm.so+0x209767]
V [libjvm.so+0x280f8c]
V [libjvm.so+0x280839]
V [libjvm.so+0x66feb6]
V [libjvm.so+0x66959e]
V [libjvm.so+0x57a89e]
C [libpthread.so.0+0x5832]
Current CompileTask:
C2:3230 ! org.apache.jsp.com.common.press_jsp._jspService(Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServletResponse;)V (4433 bytes)
--------------- P R O C E S S ---------------
Java Threads: ( => current thread )
0x09a21400 JavaThread "http-8080-exec-904" daemon [_thread_in_native, id=17126, stack(SIGTERM: [libjvm.so+0x57aaf0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGQUIT: [libjvm.so+0x57aaf0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
--------------- S Y S T E M ---------------
OS:Red Hat Enterprise Linux Server release 5.5 (Tikanga)
uname:Linux 2.6.18-194.17.1.el5PAE #1 SMP Mon Sep 20 07:34:07 EDT 2010 i686
libc:glibc 2.5 NPTL 2.5
rlimit: STACK 10240k, CORE 0k, NPROC 114688, NOFILE 1024, AS infinity
load average:0.39 0.54 0.38
CPU:total 2 (2 cores per cpu, 1 threads per core) family 6 model 15 stepping 11, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3
Memory: 4k page, physical 6228576k(225096k free), swap 6974456k(6974352k free)
vm_info: Java HotSpot(TM) Server VM (17.0-b16) for linux-x86 JRE (1.6.0_21-b06), built on Jun 22 2010 01:04:46 by "java_re" with gcc 3.2.1-7a (J2SE release)
time: Fri Dec 10 14:01:06 2010
elapsed time: 79552 seconds
Thanks in advance,
Amit

For the record (and Google), this looks like both these bugs, which were fixed in the 1.6u22 release of sun's jdk. So, first thing to do is update your JVM. If it still happens, and always happens on a particular method, you can exclude that method from compilation (as long as you're aware of the performance implications of that) with the following jvm flag:
-XX:CompileCommand=exclude,org/apache/velocity/runtime/directive/Foreach,render
(as suggested here). But, first update your jvm.

You're running with a lot of JVM args that affect memory. Have you tried empirically removing each option to see which one is causing the OOM? This particular OOM is not coming from the Java heap, it's coming from the JVM's own C heap.

As stated by the other answers / comments, you are running out of memory. Given your JVM settings, I'd say that the root cause is 99% likely to be a memory leak.
If you have been doing a lot of hot loading in the Tomcat instance, this could just be caused by that. Hot loading is notorious for leaking memory, and there is not much you can do about it in practice ... except exit and restart your Tomcat more often.
The other possibility is that your application is leaking memory. If this is the case then you will need to use a memory profiler to track down the leak.
The fact that the OOME caused a JVM crash is interesting, but probably not significant. (It looks like the JVM was trying to JIT compile a class generated from a JSP when it ran out of memory. The chunk being requested is rather large, but that probably means you have a rather large / complicated JSP.)