JDK-8146546 : assert(fr->safe_for_sender(thread)) failed: Safety check
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • CPU: x86,x86_64
  • Submitted: 2016-01-06
  • Updated: 2016-10-13
  • Resolved: 2016-09-26
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 b140Fixed
Related Reports
Relates :  
Description
;; Using jvm: "c:/users/aurora/CommonData/JDK_DIR/bin/server/jvm.dll"
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (C:\jprt\T\P1\100929.vkozlov\s\hotspot\src\os\windows\vm\os_windows.cpp:2384), pid=152228, tid=64988
#  assert(fr->safe_for_sender(thread)) failed: Safety check
#
# JRE version: Java(TM) SE Runtime Environment (9.0) (build 9-internal+0-2015-12-29-100929.vkozlov.8144993)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (9-internal+0-2015-12-29-100929.vkozlov.8144993, compiled mode, tiered, compressed oops, g1 gc, windows-amd64)
# Core dump will be written. Default location: C:\Users\aurora\sandbox\results\workDir\closed\runtime\4984318\Test4984318\hs_err_pid152228.mdmp
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#

---------------  T H R E A D  ---------------

Current thread (0x000000de6e5ea800):  JavaThread "MainThread" [_thread_in_Java, id=64988, stack(0x000000de735e0000,0x000000de736e0000)]

Stack: [0x000000de735e0000,0x000000de736e0000]
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0x523c20]  os::platform_print_native_stack+0x100;;  ?platform_print_native_stack@os@@SA_NPEAVoutputStream@@PEBXPEADH@Z+0x100
V  [jvm.dll+0x3d152f]  VMError::report+0xabf;;  ?report@VMError@@CAXPEAVoutputStream@@_N@Z+0xabf
V  [jvm.dll+0x3d23f7]  VMError::report_and_die+0x477;;  ?report_and_die@VMError@@SAXHPEBD0PEADPEAVThread@@PEAEPEAX40H_K@Z+0x477
V  [jvm.dll+0x3d29ed]  VMError::report_and_die+0x5d;;  ?report_and_die@VMError@@SAXPEAVThread@@PEBDH11PEAD@Z+0x5d
V  [jvm.dll+0x3bb018]  report_vm_error+0x78;;  ?report_vm_error@@YAXPEBDH00ZZ+0x78
V  [jvm.dll+0x427ab9]  os::win32::get_frame_at_stack_banging_point+0x219;;  ?get_frame_at_stack_banging_point@win32@os@@SA_NPEAVJavaThread@@PEAU_EXCEPTION_POINTERS@@PEAEPEAVframe@@@Z+0x219
V  [jvm.dll+0x42cfcc]  topLevelExceptionFilter+0x18c;;  ?topLevelExceptionFilter@@YAJPEAU_EXCEPTION_POINTERS@@@Z+0x18c
V  [jvm.dll+0x5238de]  HandleExceptionFromCodeCache+0x2e;;  ?HandleExceptionFromCodeCache@@YAJPEAU_EXCEPTION_RECORD@@_KPEAU_CONTEXT@@PEAU_DISPATCHER_CONTEXT@@@Z+0x2e
C  [ntdll.dll+0x93f1d]
C  [ntdll.dll+0x54897]
C  [ntdll.dll+0x930aa]
C  0x000000de55b28fc9

Comments
The issue seems to be that safe_for_sender() is used for different purposes in different contexts. JFR uses this method to check if it is safe to walk the stack, if the method returns false, JFR simply record the current event without stack information. JFR has to be very conservative on the conditions to be satisfied to safely walk the stack, because JFR events could occur at any time. In the current case, safe_for_sender() is not called by JFR, but by the reserved stack management code. The implementation of the reserved stack requires to walk the stack too, but always on well defined points in execution: when the stack banging is performed to detect potential stack overflow ahead of time. Because the reserved stack code knows exactly the state of the stack when it has to browse it, it has less constraints than the JFR code. The condition that makes safe_for_sender() to return false here, and by consequence causes the assertion failure, are harmless for the reserved stack code. Removing the condition in safe_for_sender() doesn't seem a good idea, as it could be harmful for JFR code. However, removing the assertion in the reserved stack code should be harmless.
09-09-2016

ILW = assert; intermittent failure affecting 3 tests; none = MMH = P3
07-06-2016

The deopt check in Frame::safe_for_sender() was added long ago by JDK-8005849: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/bb74dc5ddf07#l21.146 I'm not sure why we check this only on x86. I also wonder if the assert is required. Seems like it's only used for profiling code and not for general stack walking. We don't have such checks in SharedRuntime::look_for_reserved_stack_annotated_method(). [~fparain], can you have a look?
30-03-2016

This is different than JDK-8150821. We fail in get_frame_at_stack_banging_point() because fr->safe_for_sender(thread) is false. The frame is: Interpreted frame (sp=0xfffffd7ffef08ff0 unextended sp=0xfffffd7ffef08ff0, fp=0xfffffd7ffefee8d0, real_fp=0xfffffd7ffefee8d0, pc=0xfffffd7fe864f65a) (~monitorenter 194 monitorenter [0xfffffd7fe864f280, 0xfffffd7fe864f700] 1152 bytes) Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j Crash.test()I+26 J 727 C1 Test4984318.main([Ljava/lang/String;)V (37 bytes) @ 0xfffffd7fe90171a4 [0xfffffd7fe9017120+0x0000000000000084] v ~StubRoutines::call_stub V [libjvm.so+0x17c96f2] void JavaCalls::call_helper(JavaValue*,const methodHandle&,JavaCallArguments*,Thread*)+0x392 V [libjvm.so+0x1875471] void jni_invoke_static(JNIEnv_*,JavaValue*,_jobject*,JNICallType,_jmethodID*,JNI_ArgumentPusher*,Thread*)+0x2a1 V [libjvm.so+0x189f916] jni_CallStaticVoidMethod+0x3e6 C [libjli.so+0xb348] JavaMain+0x2a8 C [libc.so.1+0x12257d] _thrp_setup+0xa5 C [libc.so.1+0x122820] _lwp_start+0x0 Frame::safe_for_sender() returns false because sender_blob "Test4984318.main" is deopted (we run with -XX:+DeoptimizeALot). I'm investigating how to fix this.
24-03-2016

Could be similar problem to JDK-8150821 since it also happens with --XX:+DeoptimizeALot and in the code added by JDK-8046936. Tobias, please, check if your 8150821 fix should be done for x64 too to fix this problem.
23-03-2016

SEGV somewhere in C1 stub: [t@2 l@2]: x 0xfffffd7fe9e10b00/60i 0xfffffd7fe9e10b00: nop 0xfffffd7fe9e10b01: nop 0xfffffd7fe9e10b02: nop 0xfffffd7fe9e10b03: nop 0xfffffd7fe9e10b04: nop 0xfffffd7fe9e10b05: movq $0x0000000000000000,%rbx 0xfffffd7fe9e10b0f: jmp 0xfffffd7fe9e10b0f [ 0xfffffd7fe9e10b0f, .+0 ] 0xfffffd7fe9e10b14: nop 0xfffffd7fe9e10b15: movq $0xfffffd7fd3000938,%rbx 0xfffffd7fe9e10b1f: jmp 0xfffffd7fe9559b5e [ 0xfffffd7fe9559b5e, .-0x8b6fc1 ] 0xfffffd7fe9e10b24: nop 0xfffffd7fe9e10b25: movq $0x0000000000000000,%rbx 0xfffffd7fe9e10b2f: jmp 0xfffffd7fe9e10b2f [ 0xfffffd7fe9e10b2f, .+0 ] 0xfffffd7fe9e10b34: nop 0xfffffd7fe9e10b35: movq $0x0000000000000000,%rbx 0xfffffd7fe9e10b3f: jmp 0xfffffd7fe9e10b3f [ 0xfffffd7fe9e10b3f, .+0 ] 0xfffffd7fe9e10b44: movq $0x000000000000dead,%rbx 0xfffffd7fe9e10b4e: movq $0x000000000000dead,%rcx 0xfffffd7fe9e10b58: movq $0x000000000000dead,%rsi 0xfffffd7fe9e10b62: movq $0x000000000000dead,%rdi 0xfffffd7fe9e10b6c: call 0xfffffd7fe983f320 [ 0xfffffd7fe983f320, .-0x5d184c ] 0xfffffd7fe9e10b71: movq %rsp,0xffffffffffffffd8(%rsp) 0xfffffd7fe9e10b76: subq $0x0000000000000080,%rsp 0xfffffd7fe9e10b7d: movq %rax,0x0000000000000078(%rsp) 0xfffffd7fe9e10b82: movq %rcx,0x0000000000000070(%rsp) 0xfffffd7fe9e10b87: movq %rdx,0x0000000000000068(%rsp) 0xfffffd7fe9e10b8c: movq %rbx,0x0000000000000060(%rsp) 0xfffffd7fe9e10b91: movq %rbp,0x0000000000000050(%rsp) 0xfffffd7fe9e10b96: movq %rsi,0x0000000000000048(%rsp) 0xfffffd7fe9e10b9b: movq %rdi,0x0000000000000040(%rsp) 0xfffffd7fe9e10ba0: movq %r8,0x0000000000000038(%rsp) 0xfffffd7fe9e10ba5: movq %r9,0x0000000000000030(%rsp) 0xfffffd7fe9e10baa: movq %r10,0x0000000000000028(%rsp) 0xfffffd7fe9e10baf: movq %r11,0x0000000000000020(%rsp) 0xfffffd7fe9e10bb4: movq %r12,0x0000000000000018(%rsp) 0xfffffd7fe9e10bb9: movq %r13,0x0000000000000010(%rsp) 0xfffffd7fe9e10bbe: movq %r14,0x0000000000000008(%rsp) 0xfffffd7fe9e10bc3: movq %r15,(%rsp) 0xfffffd7fe9e10bc7: movq $__RTTI__1nNResourceArray_+0x840,%rdi 0xfffffd7fe9e10bd1: movq $0xfffffd7fe9e10b71,%rsi 0xfffffd7fe9e10bdb: movq %rsp,%rdx 0xfffffd7fe9e10bde: andq $0xfffffffffffffff0,%rsp 0xfffffd7fe9e10be2: movq $debug64,%r10 0xfffffd7fe9e10bec: call *%r10d 0xfffffd7fe9e10bef: hlt 0xfffffd7fe9e10bf0: movq $0xfffffd7fe9e10bf0,%r10 0xfffffd7fe9e10bfa: pushq %r10 0xfffffd7fe9e10bfc: jmp 0xfffffd7fe950a7a0 [ 0xfffffd7fe950a7a0, .-0x90645c ] 0xfffffd7fe9e10c01: hlt 0xfffffd7fe983f320 is at code_begin+0 in [CodeBlob (0xfffffd7fe983f290)] Framesize: 2 Runtime Stub (0xfffffd7fe983f290): handle_exception_from_callee Runtime1 stub Actually 0xfffffd7fe9e10bf0 is pointing to deopt stub: 0xfffffd7fe9e10bf0: movq $0xfffffd7fe9e10bf0,%r10 0xfffffd7fe9e10bfa: pushq %r10 0xfffffd7fe9e10bfc: jmp 0xfffffd7fe950a7a0 [ 0xfffffd7fe950a7a0, .-0x90645c ] 0xfffffd7fe950a7a0 is at code_begin+0 in [CodeBlob (0xfffffd7fe950a7a0)] Framesize: 356 DeoptimizationBlob
02-02-2016

I think somehow we ended up with huge frame: rbp 0xfffffd7ffefde7f0 rbx 0x0000000000000000 rdx 0xfffffd7ffefde7b0 rcx 0x00000005e106aed8 rax 0x0000000000459805 trapno 0x000000000000000e err 0x0000000000000006 rip 0xfffffd7fe944f3f6:0xfffffd7fe944f3f6 movl %eax,0xfffffffffffea000(%rsp) cs 0x0000000000000053 eflags 0x0000000000010246 rsp 0xfffffd7ffeef8ff0 $rbp - $rsp = 940032 As result stack bang hit protected page: 0xfffffd7fe944f3f2: movq %r13,0xffffffffffffffc8(%rbp) 0xfffffd7fe944f3f6: movl %eax,0xfffffffffffea000(%rsp) 0xfffffd7fe944f3fd: movzbl 0x0000000000000000(%r13),%ebx 0xfffffd7fe944f402: movq $_active_table+0x4000,%r10 0xfffffd7fe944f40c: jmp *(%r10,%rbx,8) [t@2 l@2]: x 0xfffffd7ffeef8ff0 + 0xfffffffffffea000 0xfffffd7ffeee2ff0: dbx: read of 8 bytes at address fffffd7ffeee2ff0 failed The code above looks like from next part of TemplateTable::monitorenter() : // check to make sure this monitor doesn't cause stack overflow after locking __ save_bcp(); // in case of exception __ generate_stack_overflow_check(0); // The bcp has already been incremented. Just need to dispatch to // next instruction. __ dispatch_next(vtos);
02-02-2016

Here is how I run debug VM on solaris to reproduce the problem: java -XX:+TieredCompilation -Xcomp -XX:CompileThreshold=100 -XX:+DeoptimizeALot -XX:+UseG1GC -XX:ParallelGCThreads=2 -ea -esa -XX:+PreserveFramePointer Test4984318
01-02-2016

Running with -XX:+PreserveStackPointer does not help - address is still in handle_exception_from_callee Runtime1 stub
01-02-2016

First SEGV: current thread: t@2 [1] call_user_handler(0xb, 0xfffffd7ffeef8e70, 0xfffffd7ffeef87c0, 0x5e106aaf8, 0x0, 0x43a260), at 0xfffffd7fff255e04 [2] sigacthandler(), at 0xfffffd7fff2562cf ---- called from signal handler with signal 11 (SIGSEGV) ------ [3] 0xfffffd7fe944f3f6(0x439000, 0xfffffd7ffeef8ff0, 0xfffffd7ffefde7b0, 0x5e106aaf8, 0x0, 0x43a260), at 0xfffffd7fe944f3f6 [4] 0xffffffffffffffff(), at 0xffffffffffffffff [5] 0xfffffd7fe9e10bf0(), at 0xfffffd7fe9e10bf0 =>[6] JavaCalls::call_helper(result = 0xfffffd7ffefdee50, method = CLASS, args = 0xfffffd7ffefdebb0, __the_thread__ = 0x439000), line 415 in "/export/kvn/JDK9/8146546/hotspot/src/share/vm/runtime/javaCalls.cpp" Strange thing is top of stack is looks like interpreter frame: 0xfffffd7fe944f3f6 is at code_begin+950 in an Interpreter codelet monitorenter 194 monitorenter [0xfffffd7fe944f040, 0xfffffd7fe944f4a0] 1120 bytes It could that the stack is totally broken.
01-02-2016

get_frame_at_stack_banging_point() is new code added by JDK-8046936 changes.
01-02-2016

C1 compiled code [1] report_vm_error(file = 0xfffffd7ca186c7a3 "/export/kvn/JDK9/8146546/hotspot/src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp", line = 256, error_msg = 0xfffffd7ca186c853 "assert(fr->safe_for_sender(thread)) failed", detail_fmt = 0xfffffd7ca186c87e "Safety check", ...), line 215 in "/export/kvn/JDK9/8146546/hotspot/src/share/vm/utilities/debug.cpp" =>[2] os::Solaris::get_frame_at_stack_banging_point(thread = 0x439000, uc = 0xfffffd7ffeef87c0, fr = 0xfffffd7ffeef8540), line 256 in "/export/kvn/JDK9/8146546/hotspot/src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp" [3] JVM_handle_solaris_signal(sig = 11, info = 0xfffffd7ffeef8e70, ucVoid = 0xfffffd7ffeef87c0, abort_if_unrecognized = 1), line 472 in "/export/kvn/JDK9/8146546/hotspot/src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp" [4] signalHandler(sig = 11, info = 0xfffffd7ffeef8e70, ucVoid = 0xfffffd7ffeef87c0), line 3784 in "/export/kvn/JDK9/8146546/hotspot/src/os/solaris/vm/os_solaris.cpp" [5] __sighndlr(), at 0xfffffd7fff2628e6 [6] call_user_handler(), at 0xfffffd7fff2560ae [7] sigacthandler(), at 0xfffffd7fff2562cf ---- called from signal handler with signal 11 (SIGSEGV) ------ [8] 0xfffffd7fe944f3f6(0x439000, 0xfffffd7ffeef8ff0, 0xfffffd7ffefde7b0, 0x5e106aaf8, 0x0, 0x43a260), at 0xfffffd7fe944f3f6 [9] os::Solaris::get_frame_at_stack_banging_point(thread = 0xfffffd7ffefde820, uc = (nil), fr = 0xfffffd7fd3000938), line 256 in "/export/kvn/JDK9/8146546/hotspot/src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp" [10] 0xfffffd7fe9e10bf0(), at 0xfffffd7fe9e10bf0 [11] JavaCalls::call_helper(result = 0xfffffd7ffefdee50, method = CLASS, args = 0xfffffd7ffefdebb0, __the_thread__ = 0x439000), line 415 in "/export/kvn/JDK9/8146546/hotspot/src/share/vm/runtime/javaCalls.cpp" [12] os::os_exception_wrapper(f = 0xfffffd7ca0cf8f30 = &JavaCalls::call_helper(JavaValue*,const methodHandle&,JavaCallArguments*,Thread*), value = 0xfffffd7ffefdee50, method = CLASS, args = 0xfffffd7ffefdebb0, thread = 0x439000), line 3747 in "/export/kvn/JDK9/8146546/hotspot/src/os/solaris/vm/os_solaris.cpp" [13] JavaCalls::call(result = 0xfffffd7ffefdee50, method = CLASS, args = 0xfffffd7ffefdebb0, __the_thread__ = 0x439000), line 298 in "/export/kvn/JDK9/8146546/hotspot/src/share/vm/runtime/javaCalls.cpp" [14] jni_invoke_static(env = 0x439240, result = 0xfffffd7ffefdee50, receiver = (nil), call_type = JNI_STATIC, method_id = 0x14ddb10, args = 0xfffffd7ffefdee00, __the_thread__ = 0x439000), line 1102 in "/export/kvn/JDK9/8146546/hotspot/src/share/vm/prims/jni.cpp" [15] jni_CallStaticVoidMethod(env = 0x439240, cls = 0x43b0d0, methodID = 0x14ddb10, ...), line 1976 in "/export/kvn/JDK9/8146546/hotspot/src/share/vm/prims/jni.cpp" [16] JavaMain(_args = 0xfffffd7fffdfe9a0), line 477 in "/export/kvn/JDK9/8146546/jdk/src/java.base/share/native/libjli/java.c" [17] _thrp_setup(), at 0xfffffd7fff26257d [18] _lwp_start(), at 0xfffffd7fff262820 0xfffffd7fe9e10bf0 is at entry_point+1488 in (nmethod*)0xfffffd7fe9e10410 for {method} {0xfffffd7fd3000370} 'main' '([Ljava/lang/String;)V' in 'Test4984318' Compiled method (c1) 220445 730 ! 3 Test4984318::main (37 bytes) total in heap [0xfffffd7fe9e10410,0xfffffd7fe9e10ea0] = 2704 relocation [0xfffffd7fe9e10550,0xfffffd7fe9e10610] = 192 main code [0xfffffd7fe9e10620,0xfffffd7fe9e10b00] = 1248 stub code [0xfffffd7fe9e10b00,0xfffffd7fe9e10c08] = 264 oops [0xfffffd7fe9e10c08,0xfffffd7fe9e10c10] = 8 metadata [0xfffffd7fe9e10c10,0xfffffd7fe9e10c18] = 8 scopes data [0xfffffd7fe9e10c18,0xfffffd7fe9e10cb0] = 152 scopes pcs [0xfffffd7fe9e10cb0,0xfffffd7fe9e10e20] = 368 dependencies [0xfffffd7fe9e10e20,0xfffffd7fe9e10e28] = 8 handler table [0xfffffd7fe9e10e28,0xfffffd7fe9e10e88] = 96 nul chk table [0xfffffd7fe9e10e88,0xfffffd7fe9e10ea0] = 24
01-02-2016