JDK-8034181 : (sctp) SIGBUS in SctpChannelImpl receive
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 7u45,8,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris
  • CPU: sparc
  • Submitted: 2014-02-11
  • Updated: 2016-05-27
  • Resolved: 2014-03-25
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availabitlity Release.

To download the current JDK release, click here.
7u60Fixed 8u20Fixed 9 b08Fixed
Related Reports
Relates :  
Relates :  
 SIGBUG which running their application on  7.0_45-b18. 

hs pid file contents : 

# JRE version: Java(TM) SE Runtime Environment (7.0_45-b18) (build 
# Java VM: Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode 
solaris-sparc compressed oops) 
# Problematic frame: 
# C  [libsctp.so+0x3964]  handleNotification+0x18 <<== 
# Core dump written. Default location: /opt/LC/vMLC11_3_0/etc/core or 

# The crash happened outside the Java Virtual Machine in native code. <<== 
# See problematic frame for where to report the bug. 

---------------  T H R E A D  --------------- 
Current thread (0x00000001020f3000):  JavaThread "pool-14-thread-1" 
[_thread_in_native, id=154, stack(0xffffffff37e00000,0xffffffff37f00000)] 
siginfo:si_signo=SIGBUS: si_errno=0, si_code=1 (BUS_ADRALN), 

Stack: [0xffffffff37e00000,0xffffffff37f00000],  sp=0xffffffff37efe9a0,  free 
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native 
C  [libsctp.so+0x3964]  handleNotification+0x18 <<== 
C  [libsctp.so+0x3d20]  Java_sun_nio_ch_SctpChannelImpl_receive0+0x1d8 <<== 
J  sun.nio.ch.SctpChannelImpl.receive0(ILsun/nio/ch/SctpResultContainer;JIZ)I 
J  sun.nio.ch.SctpChannelImpl.receive(Ljava/nio/ByteBuffer;Ljava/lang/Object;Lcom 
J  com.traffix.openblox.core.transport.sctp.m.read(Ljava/nio/ByteBuffer;)I <<== 
j   com.traffix.openblox.core.transport.a.h.d(Ljava/nio/channels/SelectionKey;)Z+7 6 <<== 
J  com.traffix.openblox.core.transport.a.h.run()V <<== 

There are no any issues in 8u20 nightly that specific to the fix. So, we can take the fix into 7u60. But, please, provide a justification as Ilya requested.

To take the fix into 7u60 SQE has to perfrom nightly for the fix. Could you please push it into 7u80 first?

The problem here is that the native SCTP implementation assumes memory aligned addresses for the given byte buffer(s) ( buffer address + position ). It re-uses the given buffer for handling notifications from the SCTP Stack ( as well as for reading data off the socket ). This issue can be reproduced, always, on Solaris sparc/sparcv9 with a small modification to an existing OpenJDK test, see below. The issue is NOT reproducible on Linux x86/x64, Solaris x86/x64. diff --git a/test/com/sun/nio/sctp/SctpChannel/Receive.java b/test/com/sun/nio/sctp/SctpChannel/Receive.java --- a/test/com/sun/nio/sctp/SctpChannel/Receive.java +++ b/test/com/sun/nio/sctp/SctpChannel/Receive.java @@ -94,7 +94,7 @@ void doTest(SocketAddress peerAddress) { SctpChannel channel = null; - ByteBuffer buffer = ByteBuffer.allocate(Util.LARGE_BUFFER); + ByteBuffer buffer = ByteBuffer.allocateDirect(Util.LARGE_BUFFER); MessageInfo info; try { @@ -117,6 +117,7 @@ /* TEST 2: receive small message */ do { debug("Test 2: invoking receive"); + buffer.position(1); info = channel.receive(buffer, null, handler); if (info == null) { fail("unexpected null from receive");