RFR(S): 8134468: Lucene test failures with 32 bit JDK 9b78, Server compiler

[Uwe Schindler]

Hi,

I will try to reproduce. This happened in 2 different JVMs at the same time at same underlying Java code, so I assume that this must be somehow reproducible.

Unfortunately the test failure happens in Apache Solr (which is the server based on Lucene and it's much more hard to debug this). As the stack trace for both failures always displays the same signature, it could be a problem only with Apache Directory API (https://directory.apache.org/), which may reproduce by running their tests. I will report back.

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.

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