JDK-8159257 : unsafe.cpp: assert(byte_offset < p_size) failed: Unsafe access: offset 32767 > object's size 16
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P3
  • Status: Closed
  • Resolution: Cannot Reproduce
  • Submitted: 2016-06-10
  • Updated: 2021-04-27
  • Resolved: 2016-08-22
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 9
9Resolved
Related Reports
Relates :  
JDK-8157957 - ClassNotFoundException: jdk.test.lib.JDKToolFinder
Relates :  
JDK-8151163 - All Buffer implementations should leverage Unsafe unaligned accessors
Relates :  
JDK-8162458 - Buffer view implementations use incorrect offset for Unsafe access
Description
Nightly failure runtime/Unsafe/RangeCheck.java

#  Internal Error (hotspot/src/share/vm/prims/unsafe.cpp:113), pid=22706, tid=22707
#  assert(byte_offset < p_size) failed: Unsafe access: offset 32767 > object's size 16
#
# JRE version: Java(TM) SE Runtime Environment (9.0) (fastdebug build 9-internal+0-2016-06-08-001711.vkozlov.8158985)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 9-internal+0-2016-06-08-001711.vkozlov.8158985, compiled mode, g1 gc, linux-amd64)

Note: the error reported with the execution of the RangeCheck.java is similar to the errors reported for JDK-8162458, but the cause is different. In the later case the offset and size values are likely to differ and the stack traces will differ, a class java.nio.ByteBufferAs*Buffer* will appear in the Java stack trace.
Comments
The Kitchensink crash hasn't been seen since August 3rd, closing as CNR.
22-08-2016
After reading the comments I'm missing where 'cause known' is coming from?
19-08-2016
@Christian: the error output of this issue is similar to that of JDK-8162458 but the causes are different. See the description of this issue.
15-08-2016
Was this issue fixed by another change? The last seen failure was 12 days ago.
15-08-2016
Ok, yes that is pointing to JDK-8151163 as the culprit. I am current running tests through JPRT, and exploring why i am getting some SEGVs on sparcv9.
25-07-2016
The reason I found this was that this was in the call stack which has java.nio.ByteBufferAsIntBufferB.get() on it. Stack: [0x00007f16d66e9000,0x00007f16d67ea000], sp=0x00007f16d67e6dd0, free space=1015k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x16a0642] VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thr ead*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x162 V [libjvm.so+0x16a13bf] VMError::report_and_die(Thread*, char const*, int, char const*, char const *, __va_list_tag*)+0x2f V [libjvm.so+0xa67a9d] report_vm_error(char const*, int, char const*, char const*, ...)+0xdd V [libjvm.so+0x163ee89] index_oop_from_field_offset_long(oop, long)+0xc9 V [libjvm.so+0x1644bd9] Unsafe_GetInt+0xe9 J 3045 jdk.internal.misc.Unsafe.getInt(Ljava/lang/Object;J)I java.base@9-internal (0 bytes) @ 0x0000 7f5a8b8e8ac5 [0x00007f5a8b8e8980+0x0000000000000145] j jdk.internal.misc.Unsafe.getIntUnaligned(Ljava/lang/Object;J)I+13 java.base@9-internal j jdk.internal.misc.Unsafe.getIntUnaligned(Ljava/lang/Object;JZ)I+5 java.base@9-internal j java.nio.ByteBufferAsIntBufferB.get()I+20 java.base@9-internal j sun.font.CMap$CMapFormat12.<init>(Ljava/nio/ByteBuffer;I[C)V+105 java.desktop@9-internal j sun.font.CMap.createCMap(Ljava/nio/ByteBuffer;I[C)Lsun/font/CMap;+204 java.desktop@9-internal j sun.font.CMap.initialize(Lsun/font/TrueTypeFont;)Lsun/font/CMap;+234 java.desktop@9-internal j sun.font.TrueTypeGlyphMapper.<init>(Lsun/font/TrueTypeFont;)V+11 java.desktop@9-internal j sun.font.TrueTypeFont.getMapper()Lsun/font/CharToGlyphMapper;+13 java.desktop@9-internal j sun.font.FileFontStrike.<init>(Lsun/font/FileFont;Lsun/font/FontStrikeDesc;)V+252 java.desktop@9- internal j sun.font.FileFont.createStrike(Lsun/font/FontStrikeDesc;)Lsun/font/FontStrike;+18 java.desktop@9- internal j sun.font.Font2D.getStrike(Lsun/font/FontStrikeDesc;Z)Lsun/font/FontStrike;+92 java.desktop@9-inte rnal j sun.font.Font2D.getStrike(Lsun/font/FontStrikeDesc;)Lsun/font/FontStrike;+3 java.desktop@9-intern The assert was: # Internal Error (/home/cphillim/hg.local/9arm/hotspot/src/share/vm/prims/unsafe.cpp:113), pid=2755 5, tid=27886 # assert(byte_offset < p_size) failed: Unsafe access: offset 5704 > object's size 5704 Your change above seems to be working in my testing.
25-07-2016
There may be additional bugs. I'll try your patch on my testing. Thank you for looking at this so quickly!
23-07-2016
I can reproduce this in jdk9/dev where JDK-8151163 is not applied.
23-07-2016
Drat, i can still reproduce when using that fix, so there could be independent bugs. When i run the test and use -verbose:class i do not observe any heap-based ByteBuffer view classes loaded, implying they are not used, and i don't see how the changes to DirectByteBuffer should affect things, the calls to Unsafe.get/put*Unaligned will intrinsicially wire up to the Unsafe.get/put* (albeit the double addressing mode variants)
23-07-2016
Webrev: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8159257-byte-buffer-view-offset-access-incorrect/webrev/
23-07-2016
JDK-8151163 had a bug in the offset calculation that was not caught by the tests and could result in writing to memory out of bounds of the buffer. I thought i could rely on the ByteBuffer.address field that encapsulates the byte offset for a ByteBuffer, but the byte offset flows in various different ways depending on how the view buffer is duplicated and sliced. Below is a patch that should fix the issue. Better tests will be written, since rather disturbingly all buffer-related tests passed. diff -r 03e2fb699fdc src/java.base/share/classes/java/nio/ByteBufferAs-X-Buffer.java.template --- a/src/java.base/share/classes/java/nio/ByteBufferAs-X-Buffer.java.template Thu Jul 21 16:29:17 2016 +0200 +++ b/src/java.base/share/classes/java/nio/ByteBufferAs-X-Buffer.java.template Sat Jul 23 06:42:38 2016 +0200 @@ -113,7 +113,7 @@ } private long byteOffset(long i) { - return (i << $LG_BYTES_PER_VALUE$) + bb.address + offset; + return (i << $LG_BYTES_PER_VALUE$) + Unsafe.ARRAY_BYTE_BASE_OFFSET + offset; } public $type$ get() {
23-07-2016
backing out the change for JDK-8151163 makes this crash go away on my local machine where it's was 100% reproduceable
22-07-2016
How is this a duplicate of JDK-8157957 ?
22-07-2016