-
Enhancement
-
Resolution: Unresolved
-
P4
-
7u76, 9, 10
A DESCRIPTION OF THE REQUEST :
Our application uses JNI to interface with the JVM. We noticed this crash on Solaris, where the JVM erroneously invokes our BoolNode class function instead of its own. The call stack is provided below.
Stack: [0xffffffff2c200000,0xffffffff2c300000], sp=0xffffffff2c2f6960, free space=986k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0xcc27ac] void VMError::report_and_die()+0x774
V [libjvm.so+0xb085a0] void _handle_uncaught_cxx_exception()+0x40
C [libCrun.so.1+0x64ec] void __Cimpl::default_unexpected()+0xc
C [libCrun.so.1+0x6430] void __Cimpl::ex_unexpected()+0x18
C [libCrun.so.1+0x74e8] void __Crun::ex_chk_unexpected()+0x80
C [libCrun.so.1+0x7440] bool __Crun::ex_skip()+0x70
C [libCstd.so.1+0x114f84] std::basic_ostream<char,std::char_traits<char> >&std::operator<<(std::basic_ostream<char,std::char_traits<char> >&,const char*)+0x934
C [statserv_64+0x493ad0] void BoolNode::Serialize(std::basic_ostream<char,std::char_traits<char> >&)+0x48
V [libjvm.so+0x20e9ac] Node*PhaseGVN::transform_no_reclaim(Node*)+0x9c
V [libjvm.so+0x711ee8] void GraphKit::gen_stub(unsigned char*,const char*,int,bool,bool)+0x1ac0
V [libjvm.so+0x5c5078] Compile::Compile #Nvariant 1(ciEnv*,const TypeFunc*(*)(),unsigned char*,const char*,int,bool,bool,bool)+0x4b0
V [libjvm.so+0xba6750] _$c1A.__1cLOptoRuntimeNgenerate_stub6FpnFciEnv_pF_pknITypeFunc_pCpkcibbb_8_+0xa8
V [libjvm.so+0x348830] void OptoRuntime::generate(ciEnv*)+0x70
V [libjvm.so+0x508bc8] void C2Compiler::initialize_runtime()+0x118
V [libjvm.so+0x369db8] void AbstractCompiler::initialize_runtimes(void(*)(),volatile int*)+0x268
V [libjvm.so+0x349a30] void C2Compiler::initialize()+0x48
V [libjvm.so+0x28dcb8] void C2Compiler::compile_method(ciEnv*,ciMethod*,int)+0x38
V [libjvm.so+0x28ee4c] void CompileBroker::invoke_compiler_on_method(CompileTask*)+0xb34
V [libjvm.so+0x310a1c] void CompileBroker::compiler_thread_loop()+0x95c
V [libjvm.so+0xc528d4] void JavaThread::thread_main_inner()+0x94
V [libjvm.so+0x2d11b4] void JavaThread::run()+0x454
V [libjvm.so+0xb0786c] java_start+0x364
JUSTIFICATION :
This was a difficult issue to track down. Fixing it will save us and future developers from much undue pain and stress.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
JVM should reserve its own namespace for its classes and functions, rather than using the std namespace, especially for potentially common names like BoolNode.
ACTUAL -
Upon JVM initialization, it tries to load a plugin and crashes.
---------- BEGIN SOURCE ----------
Crash is triggered with any java source.
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
We namespaced our own classes to avoid name collision.
Our application uses JNI to interface with the JVM. We noticed this crash on Solaris, where the JVM erroneously invokes our BoolNode class function instead of its own. The call stack is provided below.
Stack: [0xffffffff2c200000,0xffffffff2c300000], sp=0xffffffff2c2f6960, free space=986k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0xcc27ac] void VMError::report_and_die()+0x774
V [libjvm.so+0xb085a0] void _handle_uncaught_cxx_exception()+0x40
C [libCrun.so.1+0x64ec] void __Cimpl::default_unexpected()+0xc
C [libCrun.so.1+0x6430] void __Cimpl::ex_unexpected()+0x18
C [libCrun.so.1+0x74e8] void __Crun::ex_chk_unexpected()+0x80
C [libCrun.so.1+0x7440] bool __Crun::ex_skip()+0x70
C [libCstd.so.1+0x114f84] std::basic_ostream<char,std::char_traits<char> >&std::operator<<(std::basic_ostream<char,std::char_traits<char> >&,const char*)+0x934
C [statserv_64+0x493ad0] void BoolNode::Serialize(std::basic_ostream<char,std::char_traits<char> >&)+0x48
V [libjvm.so+0x20e9ac] Node*PhaseGVN::transform_no_reclaim(Node*)+0x9c
V [libjvm.so+0x711ee8] void GraphKit::gen_stub(unsigned char*,const char*,int,bool,bool)+0x1ac0
V [libjvm.so+0x5c5078] Compile::Compile #Nvariant 1(ciEnv*,const TypeFunc*(*)(),unsigned char*,const char*,int,bool,bool,bool)+0x4b0
V [libjvm.so+0xba6750] _$c1A.__1cLOptoRuntimeNgenerate_stub6FpnFciEnv_pF_pknITypeFunc_pCpkcibbb_8_+0xa8
V [libjvm.so+0x348830] void OptoRuntime::generate(ciEnv*)+0x70
V [libjvm.so+0x508bc8] void C2Compiler::initialize_runtime()+0x118
V [libjvm.so+0x369db8] void AbstractCompiler::initialize_runtimes(void(*)(),volatile int*)+0x268
V [libjvm.so+0x349a30] void C2Compiler::initialize()+0x48
V [libjvm.so+0x28dcb8] void C2Compiler::compile_method(ciEnv*,ciMethod*,int)+0x38
V [libjvm.so+0x28ee4c] void CompileBroker::invoke_compiler_on_method(CompileTask*)+0xb34
V [libjvm.so+0x310a1c] void CompileBroker::compiler_thread_loop()+0x95c
V [libjvm.so+0xc528d4] void JavaThread::thread_main_inner()+0x94
V [libjvm.so+0x2d11b4] void JavaThread::run()+0x454
V [libjvm.so+0xb0786c] java_start+0x364
JUSTIFICATION :
This was a difficult issue to track down. Fixing it will save us and future developers from much undue pain and stress.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
JVM should reserve its own namespace for its classes and functions, rather than using the std namespace, especially for potentially common names like BoolNode.
ACTUAL -
Upon JVM initialization, it tries to load a plugin and crashes.
---------- BEGIN SOURCE ----------
Crash is triggered with any java source.
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
We namespaced our own classes to avoid name collision.