jvm core dump with libnet.so

[the.6th.month at gmail.com]

hi, all:

We just encountered core dumps with our java process several times in
recent hours, and we've collected two core dump files and made a brief
analysis with gdb. According to the backtrace, both core dumps seem to be
resulted from libnet.so. The backtrace info is pasted as follows:

core dump 1
warning: no loadable sections found in added symbol-file system-supplied
DSO at 0x7fff497d6000
Core was generated by `/home/q/java/jdk1.6.0_26/bin/java
-Djava.util.logging.config.file=/home/q/www/t'.
Program terminated with signal 11, Segmentation fault.
#0  0x00000030b160de70 in send () from /lib64/libpthread.so.0
(gdb) bt
#0  0x00000030b160de70 in send () from /lib64/libpthread.so.0
#1  0x00002aaab8e88843 in NET_Send () from
/home/q/java/jdk1.6.0_26/jre/lib/amd64/libnet.so
#2  0x00002aaab8e85666 in Java_java_net_SocketOutputStream_socketWrite0 ()
from /home/q/java/jdk1.6.0_26/jre/lib/amd64/libnet.so

core dump 2
warning: no loadable sections found in added symbol-file system-supplied
DSO at 0x7fff979fc000
Core was generated by `/home/q/java/jdk1.6.0_26/bin/java
-Djava.util.logging.config.file=/home/q/www/t'.
Program terminated with signal 11, Segmentation fault.
#0  0x00000030b0e8c42b in gettimeofday () from /lib64/libc.so.6
(gdb) bt
#0  0x00000030b0e8c42b in gettimeofday () from /lib64/libc.so.6
#1  0x00002aaab8b4bd42 in NET_Timeout () from
/home/q/java/jdk1.6.0_26/jre/lib/amd64/libnet.soCentOS release 5.6 (Final
#2  0x00002aaab8b483c5 in Java_java_net_SocketInputStream_socketRead0 ()
from /home/q/java/jdk1.6.0_26/jre/lib/amd64/libnet.so

Our program is running with hotspot jdk 6u26, and the JAVA_OPTS is as below:
-XX:+PrintGCDetails -Xss256k -XX:+UseCompressedOops -XX:+DisableExplicitGC
-XX:+PrintGCDateStamps -XX:+PrintTenuringDistribution
-Xloggc:/home/q/www/travelco/logs/gc.log-server -Xms5120m -Xmx5120m
-Xmn1536m -XX:PermSize=256m -server -Dfile.encoding=UTF-8

The OS is CentOS release 5.6 (Final), and the whole system is running on a
physical machine with 24 cores and 8 gigabytes memory.

We encountered almost the same problem a year ago, and we solved the
problem by simply changed from hotspot jdk to openjdk.
It sounds quite weird to me, and I am keen to know what the reason is for
this situation. Does anyone have any idea about that? Any help would be
truly appreciated.
Thanks very much.

All the best,
Leon