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 Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8 JDK 9
7u60Fixed 8u20Fixed 9 b08Fixed
Related Reports
Relates :  
Relates :  
Description
 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 
1.7.0_45-b18) 
# 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 
core.29316 

# 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), 
si_addr=0x000000010338ac13 

Stack: [0xffffffff37e00000,0xffffffff37f00000],  sp=0xffffffff37efe9a0,  free 
space=1018k 
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native 
code) 
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 
/sun/nio/sctp/NotificationHandler;Z)Lcom/sun/nio/sctp/MessageInfo; 
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 <<== 
 

Comments
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");
18-12-2014

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.
02-04-2014

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