JDK-6745807 : CompilerThread crash in OopFlow::build_oop_map
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 5.0u14,6u6,6u12
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: linux_redhat_5.2,solaris_10
  • CPU: x86,sparc
  • Submitted: 2008-09-08
  • Updated: 2011-02-16
  • Resolved: 2010-04-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 6
6-poolResolved
Related Reports
Duplicate :  
JDK-6798785 - Crash in OopFlow::build_oop_map: incorrect comparison of 64bit pointers
Description
Customer application had 5 crashes, using 6.0u6 JVM on linux-amd64 platform.
All crashes have identical stack trace but on different CompileTasks.

OS:Red Hat Enterprise Linux Server release 5.2 (Tikanga)
vm_info: Java HotSpot(TM) 64-Bit Server VM (10.0-b22) for linux-amd64 JRE (1.6.0_06-b02) 

Decoded stacks :

V  [libjvm.so+0x1d5751] OopFlow::build_oop_map(Node*, int, PhaseRegAlloc*, int*)
+0x101
V  [libjvm.so+0x1d549a] OopFlow::compute_reach(PhaseRegAlloc*, int, Dict*)+0x24a
V  [libjvm.so+0x1d5d0c] Compile::BuildOopMaps()+0x34c
V  [libjvm.so+0x50ab05] Compile::Output()+0x2b5
V  [libjvm.so+0x24479b] Compile::Code_Gen()+0x55b
V  [libjvm.so+0x2410f5] Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bo
ol)+0x7c5
V  [libjvm.so+0x1e05f7] C2Compiler::compile_method(ciEnv*, ciMethod*, int)+0x67
V  [libjvm.so+0x248f88] CompileBroker::invoke_compiler_on_method(CompileTask*)+0
x298
V  [libjvm.so+0x248926] CompileBroker::compiler_thread_loop()+0x306
V  [libjvm.so+0x62a7a9] compiler_thread_entry(JavaThread*, Thread*)+0x9
V  [libjvm.so+0x624a51] JavaThread::run()+0x111
V  [libjvm.so+0x50628a] java_start(Thread*)+0x14a

hs_err files are in attachment.
Comments
EVALUATION I believe I've discovered the problem. The liveness analysis uses a Dict to keep track of the mapping between Nodes and int* that represents the bitmap. The default comparison function used by that Dict is this: int32 cmpkey(const void *key1, const void *key2) { return (int32)((intptr_t)key1 - (intptr_t)key2); } This effectively throws away the high 32 bits of pointers in 64-bit mode, so if we happen to put two pointers into the Dict that only differ by their high 32 bits then they will be considered the same. In the first core file the node that's being processed when we crash is node 35 which is CallStaticJavaDirectNode. Looking at the rest of the nodes I find this: 0x0000000044512890 35 CallStaticJavaDirectNode 7356 13 14 15 16 42 10609 9109 0 0 10609 9109 0 0 0 9112 9113 [[36 34 8810 ]] 0x00002aad44512890 568 CallStaticJavaDirectNode 7541 0 663 15 0 673 10609 10769 0 0 10609 10769 0 674 0 [[569 567 708 715 743 8837 ]] Node 568 has the same low bits in it's address but differs in the high 32 bits. So for this to occur several things have to be true. The nodes must both be MachSafePointNodes of some kind and they must differ only by the top bits. The fix could go one of two ways. Either change cmpkey to perform compares and return -1,0,1, change the signature of the compare function to intptr_t to maintain compare as a directional test, or convert it into a bool to make it just an equality test. All the uses I see would allow it to be a bool but it might just be safer to take the first option.
23-01-2009