JDK-8153356 : NullCheckDroppingsTest.java fails with "assert(alias_type->adr_type()..."
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: linux
  • CPU: aarch64
  • Submitted: 2016-04-04
  • Updated: 2016-07-18
  • Resolved: 2016-07-18
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
Duplicate :  
Relates :  
Relates :  
Description
The test compiler/intrinsics/classcast/NullCheckDroppingsTest.java fails in the compiler nightlies of 2016-04-01. Here is the stack trace:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/opt/jprt/T/P1/153346.dmitrij/s/hotspot/src/share/vm/opto/library_call.cpp:2526), pid=23163, tid=23193
#  assert(alias_type->adr_type() == TypeRawPtr::BOTTOM || alias_type->adr_type() == TypeOopPtr::BOTTOM || alias_type->field() != __null || alias_type->element() != __null) failed: field, array element or unknown
#
# JRE version: Java(TM) SE Runtime Environment (9.0) (fastdebug build 9-internal+0-2016-04-01-153346.dmitrij.hs-comp)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 9-internal+0-2016-04-01-153346.dmitrij.hs-comp, mixed mode, compressed oops, g1 gc, linux-aarch64)
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %P" (or dumping to /export/local/aurora/sandbox/results/workDir/compiler/intrinsics/classcast/NullCheckDroppingsTest/core.23163)

[...]

Current CompileTask:
C2:   5764  245    b        java.lang.invoke.LambdaForm$MH/914811991::putObjectFieldCast (43 bytes)

Stack: [0x0000007f49f00000,0x0000007f4a000000],  sp=0x0000007f49ffbb50,  free space=1006k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xf5e284]  VMError::report(outputStream*, bool)+0x1710
V  [libjvm.so+0xf5e808]  VMError::report_and_die(int, char const*, char const*, std::__va_list, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x140
V  [libjvm.so+0xf5f39c]  VMError::report_and_die(Thread*, char const*, int, char const*, char const*, std::__va_list)+0x54
V  [libjvm.so+0x63a688]  report_vm_error(char const*, int, char const*, char const*, ...)+0xe0
V  [libjvm.so+0xaf647c]  LibraryCallKit::inline_unsafe_access(bool, bool, BasicType, LibraryCallKit::AccessKind, bool)+0xef8
V  [libjvm.so+0xb0b6b8]  LibraryIntrinsic::generate(JVMState*)+0x184
V  [libjvm.so+0x6bf2a4]  Parse::do_call()+0x3ac
V  [libjvm.so+0xd107f4]  Parse::do_one_bytecode()+0x2d94
V  [libjvm.so+0xd045b4]  Parse::do_one_block()+0x3e8
V  [libjvm.so+0xd05118]  Parse::do_all_blocks()+0x12c
V  [libjvm.so+0xd06d3c]  Parse::Parse(JVMState*, ciMethod*, float)+0xac0
V  [libjvm.so+0x45ed80]  ParseGenerator::generate(JVMState*)+0xa8
V  [libjvm.so+0x5c77bc]  Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool, DirectiveSet*)+0xc2c
V  [libjvm.so+0x45da98]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, DirectiveSet*)+0x144
V  [libjvm.so+0x5d1a58]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x330
V  [libjvm.so+0x5d2464]  CompileBroker::compiler_thread_loop()+0x22c
V  [libjvm.so+0xedea68]  JavaThread::thread_main_inner()+0x1c8
V  [libjvm.so+0xedf2c0]  JavaThread::run()+0x1cc
V  [libjvm.so+0xcbb684]  java_start(Thread*)+0xf0
C  [libpthread.so.0+0x7e2c]  start_thread+0xb0

More investigation is needed to determine the cause of the failure.
Comments
This bug showed up only once and I was not able to reproduce it after 6000 runs (same machine/build). Closing as "Cannot reproduce".
11-04-2016

I was not able to reproduce this after 1000 runs on the same machine with the same build. Removed integration_blocker label as this is most likely a regression introduced by JDK-8140309 which is already in b96.
06-04-2016

This assert was added by JDK-8136473 and caused many problems after integration (see JDK-8140267). The fix was backed out and re-implemented with JDK-8140309 by slightly changing the assert: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-November/019696.html
05-04-2016