segfault with 8u5

Igor Veresov igor.veresov at oracle.com
Fri May 16 21:59:04 UTC 2014


It also just deopted with Reason_uninitialized, I wonder if it’s the same call site.

Event: 11862.911 Thread 0x00007fe9567ca800 Uncommon trap: reason=uninitialized action=reinterpret pc=0x00007fe95073dab0 method=ScanFilterAndProjectOperator_699.project_0(Lcom/facebook/presto/spi/RecordCursor;Lcom/facebook/presto/spi/block/BlockBuilder;)V @ 166

igor


On May 16, 2014, at 2:37 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

> 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
>> 
>> 
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140516/56d22ddf/attachment.html>


More information about the hotspot-compiler-dev mailing list