segfault with 8u5
Vladimir Kozlov
vladimir.kozlov at oracle.com
Fri May 16 21:37:56 UTC 2014
The failure happened in C1 JIT compiler (first tier). You can try to
switch off -XX:-TieredCompilation.
The failure happens in next line in inlined ptype_slot_count():
_size( method_type->ptype_slot_count()),
int ptype_slot_count() const {
GUARDED_VM_ENTRY(return
java_lang_invoke_MethodType::ptype_slot_count(get_oop());)
}
0x00007f59aa5bc5b0: ciSignature+0x0170: movq
0xffffffffffffffc8(%rbp),%rdx
0x00007f59aa5bc5b4: ciSignature+0x0174: movq
0x0000000000000010(%rdx),%rax
0x00007f59aa5bc5b8: ciSignature+0x0178: movq (%rax),%rdi
0x00007f59aa5bc5bb: ciSignature+0x017b: call ptype_slot_count [
0x7f59aa7f4320, .+0x237d65 ]
RAX=0x0000000000000000
Looks like method_type->_handle returned by get_oop() is NULL.
The only bug I found which could be related is next:
https://bugs.openjdk.java.net/browse/JDK-8029381
Regards,
Vladimir
On 5/16/14 12:39 PM, Martin Traverso wrote:
> We're testing Presto (https://github.com/facebook/presto) on Java 8, and
> ran into a segfault in the VM. Below is the relevant portion from the
> crash report. You can see the full dump here:
> https://gist.github.com/martint/364a12d4f776a6e54911
>
> Stack: [0x00007fe8a1a6c000,0x00007fe8a1b6d000], sp=0x00007fe8a1b6abe0,
> free space=1018k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
> C=native code)
> V [libjvm.so+0x3fd2f8] ciSignature::ciSignature(ciKlass*, ciSymbol*,
> ciMethodType*)+0x178
> V [libjvm.so+0x403ba7] ciBytecodeStream::get_method(bool&,
> ciSignature**)+0x4a7
>
> V [libjvm.so+0x332099] GraphBuilder::invoke(Bytecodes::Code)+0x39
> V [libjvm.so+0x333b3d] GraphBuilder::iterate_bytecodes_for_block(int)+0x6ad
>
> V [libjvm.so+0x330fa2] GraphBuilder::iterate_all_blocks(bool)+0xf2
> V [libjvm.so+0x335a97] GraphBuilder::GraphBuilder(Compilation*,
> IRScope*)+0x517
>
> V [libjvm.so+0x33e337] IRScope::IRScope(Compilation*, IRScope*, int,
> ciMethod*, int, bool)+0x1e7
> V [libjvm.so+0x33e44f] IR::IR(Compilation*, ciMethod*, int)+0x9f
>
> V [libjvm.so+0x31d74b] Compilation::build_hir()+0xdb
> V [libjvm.so+0x31db0e] Compilation::compile_java_method()+0x6e
> V [libjvm.so+0x31dc3e] Compilation::compile_method()+0x4e
> V [libjvm.so+0x31df9f] Compilation::Compilation(AbstractCompiler*,
> ciEnv*, ciMethod*, int, BufferBlob*)+0x24f
>
> V [libjvm.so+0x31ed39] Compiler::compile_method(ciEnv*, ciMethod*, int)+0xa9
> V [libjvm.so+0x46982a]
> CompileBroker::invoke_compiler_on_method(CompileTask*)+0xc8a
>
> V [libjvm.so+0x46c230] CompileBroker::compiler_thread_loop()+0x620
> V [libjvm.so+0x9e303f] JavaThread::thread_main_inner()+0xdf
>
> V [libjvm.so+0x9e3205] JavaThread::run()+0x1b5
> V [libjvm.so+0x8a00c8] java_start(Thread*)+0x108
>
>
> Is this a known issue? I couldn't find anything related in the bug
> database. Otherwise, any suggestions for debugging it would be very much
> appreciated!
>
> The problem only seems to happen after Presto has been running for a
> while and has processed several hundred queries. I’ve tried re-running
> the queries that were running at the moment it crashed, but it does not
> reproduce deterministically. Also, we don't see it in Java 7.
>
> Thanks!
>
> Martin
>
>
>
More information about the hotspot-compiler-dev
mailing list