Java crashes in SocketOutputStream.socketWrite0 from libnet.so

Solution Verified - Updated

Environment

  • JBoss Enterprise Application Platform (EAP)
  • Java

Issue

  • JBoss/Java crashed in SocketOutputStream.socketWrite0 from libnet.so from a segmentation fault. There was no hs_err file generated to provide information on this crash. We captured a core from the crash instead and its backtrace indicated the following crashpoint:
Thread 1 (Thread 0x7fe1053d3700 (LWP 3936)):
#0  0x00007fe15503c5cd in Java_java_net_SocketOutputStream_socketWrite0 () from /opt/jboss/java/jdk1.6.0_25/jre/lib/amd64/libnet.so

Resolution

  • Increase the StackShadowPages JVM setting so that more stack space is reserved for native code:
-XX:StackShadowPages=20
  • Note that will leave less stack for java level code and so the entire thread stack (-Xss) may need to be increased so that the amount of stack available to java level code is not decreased as a consequence.

Root Cause

  • Per the following Content from bugs.sun.com is not included.Oracle JDK bug report, socketWrite had a buffer increase, which increased its native stack usage. Java code has to share the stack with native code such as socketWrite. A portion of that stack will be reserved specifically for native code per the JVM's StackShadowPages setting. The default StackShadowPages setting no longer reserves enough stack for socketWrite's buffer size so if java level code recursion uses the rest of the stack except the StackShadowPages reserved space, the socketWrite can crash. A StackOverflow in this native code will produce no hs_err file.

Diagnostic Steps

SBR
Product(s)
Components
Tags

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.