segfault with 8u5

Martin Traverso mtraverso at gmail.com
Thu Sep 11 21:05:53 UTC 2014


Hi Vladimir,

I finally got around to building a fastdebug VM. I don't see the first
crash anymore (great!), but the second one still happens. Here's the output:

https://gist.github.com/martint/abea9be3df700236ec0b

Let me know if there's anything other information you'd like me to gather.

Thanks!
Martin

On Wed, Jul 30, 2014 at 10:29 AM, Vladimir Kozlov <
vladimir.kozlov at oracle.com> wrote:

> Martin,
>
> It would be also nice if you can build fastdebug VM and run with it.
> cd hotspot/make; make fastdebug LP64=1
>
> Thanks,
> Vladimir
>
>
> On 7/30/14 9:40 AM, Vladimir Kozlov wrote:
>
>> 8029381 was fixed in jdk9 and 8u20 (which should be release soon):
>>
>> http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/0b9500028980
>>
>> I will look on C2 crash more. I don't remember any recent problems in
>> catch_inline_exceptions().
>>
>> Regards,
>> Vladimir
>>
>> On 5/19/14 12:24 PM, Martin Traverso wrote:
>>
>>>     The failure happened in C1 JIT compiler (first tier). You can try
>>> to switch off -XX:-TieredCompilation.
>>>
>>>
>>> That seemed to have worked around this particular issue.
>>>
>>> However, we ran into another crash:
>>>
>>> Stack: [0x00000000430c8000,0x00000000431c9000], sp=0x00000000431c5980,
>>> free space=1014k
>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
>>> C=native code)
>>>
>>> V [libjvm.so+0x814115] LoadKlassNode::make(PhaseGVN&, Node*, Node*,
>>> TypePtr const*, TypeKlassPtr const*)+0x45
>>> V [libjvm.so+0x51ab06]
>>> Parse::catch_inline_exceptions(SafePointNode*)+0x936
>>>
>>> V [libjvm.so+0x8c1a5a] Parse::do_exceptions()+0xba
>>> V [libjvm.so+0x8c6100] Parse::do_one_block()+0x180
>>> V [libjvm.so+0x8c6377] Parse::do_all_blocks()+0x127
>>> V [libjvm.so+0x8c95d3] Parse::Parse(JVMState*, ciMethod*, float,
>>> Parse*)+0x15a3
>>> V [libjvm.so+0x3b6529] ParseGenerator::generate(JVMState*, Parse*)+0x99
>>> V [libjvm.so+0x3b7202] PredictedCallGenerator::generate(JVMState*,
>>> Parse*)+0x2a2
>>> V [libjvm.so+0x51aefd] Parse::do_call()+0x1cd
>>> V [libjvm.so+0x8d3c7a] Parse::do_one_bytecode()+0x32da
>>> V [libjvm.so+0x8c60f8] Parse::do_one_block()+0x178
>>>
>>> V [libjvm.so+0x8c6377] Parse::do_all_blocks()+0x127
>>> V [libjvm.so+0x8c95d3] Parse::Parse(JVMState*, ciMethod*, float,
>>> Parse*)+0x15a3
>>>
>>> V [libjvm.so+0x3b6529] ParseGenerator::generate(JVMState*, Parse*)+0x99
>>> V [libjvm.so+0x46111c] Compile::Compile(ciEnv*, C2Compiler*,
>>> ciMethod*, int, bool, bool, bool)+0x128c
>>>
>>> V [libjvm.so+0x3b5008] C2Compiler::compile_method(ciEnv*, ciMethod*,
>>> int)+0x198
>>> 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
>>>
>>>
>>>
>>> Full dump here: https://gist.github.com/martint/783cf3e30c17fc897423
>>>
>>>
>>>     The only bug I found which could be related is next:
>>>
>>>     https://bugs.openjdk.java.net/__browse/JDK-8029381
>>> <https://bugs.openjdk.java.net/browse/JDK-8029381>
>>>
>>>
>>> Unfortunately, I can't see this bug report. I get redirected to the
>>> login screen.
>>>
>>>
>>> Thanks!
>>> Martin
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140911/16bc77b8/attachment.html>


More information about the hotspot-compiler-dev mailing list