JDK-8140630 : java/nio/Buffer/Basic.java crashes vm on linux-x64 using latest devkit to build
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.nio
  • Affected Version: 9
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2015-10-28
  • Updated: 2016-09-23
  • Resolved: 2015-11-04
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
9 b92Fixed
Related Reports
Relates :  
JDK-8141491 - Unaligned memory access in Bits.c
Description
java/nio/Buffer/Basic.java crashes vm on linux-x64 (and openonly) when jdk is built using latest devkit (4.9.2).

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f8895af8033, pid=4860, tid=4950
#
# JRE version: Java(TM) SE Runtime Environment (9.0-b105) (build 1.9.0-ea-b105)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (1.9.0-ea-b105, mixed mode, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# C  [libjava.so+0xd033]  Java_java_nio_Bits_copyToShortArray+0x1f3
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e" (or dumping to /scratch/ssides/test/temp2/JTwork/scratch/core.4860)
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Comments
URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/9ecb10ce62c6 User: lana Date: 2015-11-11 22:11:44 +0000
11-11-2015
The fix is in jdk9/dev, it is not yet integrated into jdk9 master.
11-11-2015
URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/9ecb10ce62c6 User: bpb Date: 2015-11-04 22:08:30 +0000
04-11-2015
Review thread: http://mail.openjdk.java.net/pipermail/build-dev/2015-November/015868.html
04-11-2015
This change resolves the problem at hand: --- a/make/lib/CoreLibraries.gmk Thu Oct 29 12:39:08 2015 -0700 +++ b/make/lib/CoreLibraries.gmk Tue Nov 03 10:30:40 2015 -0800 @@ -139,6 +139,13 @@ endif endif +ifeq ($(OPENJDK_TARGET_OS), linux) + ifeq ($(OPENJDK_TARGET_CPU), x86_64) + BUILD_LIBJAVA_Bits.c_CFLAGS := $(CFLAGS_JDKLIB) $(LIBJAVA_CFLAGS) \ + $(C_O_FLAG_NORM) + endif +endif + $(eval $(call SetupNativeCompilation,BUILD_LIBJAVA, \ LIBRARY := java, \ OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \
04-11-2015
Thanks, Erik: I'll remove the extraneous flags.
04-11-2015
The BUILD_LIBJAVA_Bits.c_CFLAGS just adds, so you shouldn't need to add $(CFLAGS_JDKLIB) $(LIBJAVA_CFLAGS) again.
04-11-2015
The simplest way of lowering optimization for one file is to add this to the SetupNativeCompilation call: Bits.c_CFLAGS := $(C_O_FLAG_NORM) To do it conditionally, use the same pattern as in the patch above, just leaving the Bits.c_CFLAGS := <empty> when not needing to change it.
03-11-2015
RULE "java/nio/Buffer/Basic.java" Crash SIGSEGV
03-11-2015
No.
29-10-2015
This is core functionality and needs to be high priority to diagnose. Do you know if this is a hotspot issue or a gcc issue yet?
29-10-2015
This is a tier1 failure. If it is not to be fixed soon, it should be put on the problem list and not run.
29-10-2015
btw, if a change is in the openjdk or closedjdk 9-dev repositories, http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/20dff0211ded it will be tested by mach5. The change for 8140452 went into Mach 5 build 1105: http://java.se.oracle.com/mach5/view/All/job/9-dev-prebuild/changes and you can see by the test summary table, http://java.se.oracle.com/mach5/view/All/job/test_summary_table/, that 1 red linux-x64 failure is this bug.
28-10-2015
I believe you can see the fix in the latest build source, http://java.se.oracle.com/mach5/view/All/job/9-dev-prebuild/ws/hotspot/src/share/vm/oops/constantPool.cpp/*view*/ http://java.se.oracle.com/mach5/view/All/job/9-dev-prebuild/ws/hotspot/src/share/vm/oops/constantPool.hpp/*view*/ and the test failed. http://java.se.oracle.com/mach5/view/9-dev-test/job/9-dev-tier1-linux-x64/2803/artifact/JTwork/jdk_test/java/nio/Buffer/Basic.jtr/*view*/
28-10-2015
Crash is in libjava not libjvm so look like an issue with the new compiler and the JDK code. But could also be side-effect of the VM problem in JDK-8140452. Can you re-test with 8140452 fix applied?
28-10-2015
failuresHistory report from mach 5: http://java.se.oracle.com/mach5/view/All/job/9-dev-tier1-linux-x64-failuresHistory/Failure_History/ I ran it on command line and put core file and logs here: http://java-stage.se.oracle.com/mach5/userContent/8140630/core.4860 http://java-stage.se.oracle.com/mach5/userContent/8140630/hs_err_pid4860.log http://java-stage.se.oracle.com/mach5/userContent/8140630/Basic.jtr I built with "old" devkit (gcc4.8.2) and it passes, but it crashes when built with new devkit which uses gcc4.9.2.
28-10-2015