RFR(S): 8134468: Lucene test failures with 32 bit JDK 9b78, Server compiler
uwe at thetaphi.de
Mon Oct 5 21:18:34 UTC 2015
I got another failure with exactly same code:
So it is definitely reproducible. I was not yet able to reproduce it or test your patch (I have not much experience in doing this). Maybe Dawid Weiss has some time to try it out.
I just wanted to let you know that it is reproducible. The above Jenkins link allows to download hserr.pid and replay logs, too.
uschindler at apache.org
ASF Member, Apache Lucene PMC / Committer
> -----Original Message-----
> From: Roland Westrelin [mailto:roland.westrelin at oracle.com]
> Sent: Monday, October 05, 2015 11:55 AM
> To: Uwe Schindler
> Cc: hotspot-compiler-dev at openjdk.java.net
> Subject: Re: RFR(S): 8134468: Lucene test failures with 32 bit JDK 9b78, Server
> > Do you know when the fix for JDK-8134974 is included in EA builds? If yes,
> maybe we first try to check if it's already fixed.
> b84 it seems.
> You could try to apply the fix, it’s small:
> Or we can wait until b84 is out and see if it’s still there.
> > Uwe
> > -----
> > Uwe Schindler
> > uschindler at apache.org
> > ASF Member, Apache Lucene PMC / Committer Bremen, Germany
> > http://lucene.apache.org/
> >> -----Original Message-----
> >> From: Roland Westrelin [mailto:roland.westrelin at oracle.com]
> >> Sent: Monday, October 05, 2015 11:01 AM
> >> To: Uwe Schindler
> >> Cc: hotspot-compiler-dev at openjdk.java.net
> >> Subject: Re: RFR(S): 8134468: Lucene test failures with 32 bit JDK
> >> 9b78, Server compiler
> >> Uwe,
> >>> Thanks. I was trying b82 yesterday and we already found a new bug.
> >>> Tests
> >> were failing with SIGSEGV on Jenkins:
> >>> http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/14121/
> >>> (you can download "hs_err" and "replay" from there, you can also see
> >>> JVM
> >> settings like bitness, Garbage Collector from there).
> >> Thanks for reporting this new issue.
> >>> Current CompileTask:
> >>> C2: 866319 28632 4
> >> org.apache.directory.api.ldap.model.name.Rdn::apply (45 bytes)
> >>> Stack: [0x00007f3e647e6000,0x00007f3e648e7000],
> >>> sp=0x00007f3e648e1e60, free space=1007k Native frames: (J=compiled
> >>> Java code, j=interpreted, Vv=VM code, C=native code) V
> >>> [libjvm.so+0x80ccce]
> >>> PhaseIdealLoop::build_loop_late_post(Node*)+0x13e
> >>> V [libjvm.so+0x80d06b] PhaseIdealLoop::build_loop_late(VectorSet&,
> >>> Node_List&, Node_Stack&)+0x13b V [libjvm.so+0x8102dc]
> >>> PhaseIdealLoop::build_and_optimize(bool, bool)+0x88c V
> >>> [libjvm.so+0x4e699a] Compile::Optimize()+0x6ca V
> >>> [libjvm.so+0x4e83f0] Compile::Compile(ciEnv*, C2Compiler*,
> >>> ciMethod*, int, bool, bool, bool)+0x1040 V [libjvm.so+0x42dbb9]
> >>> C2Compiler::compile_method(ciEnv*, ciMethod*, int)+0xe9 V
> >>> [libjvm.so+0x4effda]
> >>> CompileBroker::invoke_compiler_on_method(CompileTask*)+0x8ca
> >>> V [libjvm.so+0x4f0a58] CompileBroker::compiler_thread_loop()+0x4a8
> >>> V [libjvm.so+0xa61038] JavaThread::thread_main_inner()+0xd8
> >>> V [libjvm.so+0xa611d8] JavaThread::run()+0x158 V
> >>> [libjvm.so+0x9048e2] java_start(Thread*)+0xc2 C
> >>> [libpthread.so.0+0x8182] start_thread+0xc2
> >>> siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr:
> >>> 0x0000000000000008
> >>> This happened in parallel for 2 different JVMs (we are running tests
> >>> in
> >> parallel with multiple JVMs). We should look into this, too! Tell me
> >> how I can help (as always, it is hard to reproduce). So this must be
> >> some change between b78 and b82 (b78 is last known working config).
> >> Maybe bells are ringing for you.
> >> It looks like it could be:
> >> https://bugs.openjdk.java.net/browse/JDK-8134974
> >> Can you reproduce the issue at all?
> >> Roland.=
More information about the hotspot-compiler-dev