Hi Peter, > Will you be willing to prepare it or do you need some help?
I was afraid you'd say that... ;) I'm vaguely familiar with the process, so I could try to provide a patch, but end of October seems very tight given my current schedule. I'll see what I can do though. Also, I did grep the build logs that I have available and I can confirm the problem to occur on Java 1.8 (various minors) and on IBM's Java 1.8, regardless of the target platform (Windows, Linux). ./L4G-SOFTWARE1-JDK18LINUX/download-data/build_logs/L4G-SOFTWARE1-JDK18LINUX-1052.log ./L4G-JDKS-J1IW/download-data/build_logs/L4G-JDKS-J1IW-167.log ./L4G-JDKS-J1IW/download-data/build_logs/L4G-JDKS-J1IW-174.log ./L4G-JDKS-J1IW/download-data/build_logs/L4G-JDKS-J1IW-172.log ./L4G-JDKS-J1IW/download-data/build_logs/L4G-JDKS-J1IW-155.log ./L4G-SOFTWARE-JDK18LINUX/download-data/build_logs/L4G-SOFTWARE-JDK18LINUX-1219.log ./L4G-SOFTWARE1-JDK18WINDOWS/download-data/build_logs/L4G-SOFTWARE1-JDK18WINDOWS-1088.log Dawid On Wed, Oct 18, 2017 at 8:55 AM, Peter Levart <peter.lev...@gmail.com> wrote: > Hi Dawid, > > So if we want this to be included in 8u162 [1] (to be released on January > 2018), we better hurry up and submit a backported patch before end of > October... > > I can sponsor the patch. Will you be willing to prepare it or do you need > some help? > > I think it should be a straightforward backport of JDK-8065172 [2]. > > Regards, Peter > > [1] http://openjdk.java.net/projects/jdk8u/releases/8u162.html > [2] https://bugs.openjdk.java.net/browse/JDK-8065172 > > > On 10/17/17 12:41, Dawid Weiss wrote: > > Hi Peter, > > Thanks for the pointer. Whether or not this fix should be backported > to 8u is probably not for me to decide... but if I can provide some > rationale then I think it'd be better to backport for the following > reasons: > > - This assertion isn't frequent, but it does happen from time to time. > Robert Muir also let me know in a private conversation that the > assertion was triggered from time to time in Lucene tests; the test > that mostly caused it to happen has been since disabled (for unrelated > reasons). > > - I quickly grepped the most recent Solr/Lucene logs and I see that > the assertion can be buried deep (in the suppressed exceptions chain), > which may be easily overlooked or raise false other concerns. Look at > the stack trace [1] below, for example. > > - We run tests on multiple different JVMs/ systems and I'm 99% > confident I've seen errors with this assertion on IBM's J9 too, so it > affects the whole Java ecosystem, not just OpenJDK? > > Dawid > > [1] Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20468/ > > 5 tests failed. > FAILED: > junit.framework.TestSuite.org.apache.solr.analytics.facet.QueryFacetCloudTest > > Error Message: > Error starting up MiniSolrCloudCluster > > java.lang.Exception: Error starting up MiniSolrCloudCluster > at __randomizedtesting.SeedInfo.seed([954FE60C5C176808]:0) > at > org.apache.solr.cloud.MiniSolrCloudCluster.checkForExceptions(MiniSolrCloudCluster.java:507) > at > org.apache.solr.cloud.MiniSolrCloudCluster.<init>(MiniSolrCloudCluster.java:251) > at > org.apache.solr.cloud.SolrCloudTestCase$Builder.configure(SolrCloudTestCase.java:190) > at > org.apache.solr.analytics.facet.AbstractAnalyticsFacetCloudTest.setupCluster(AbstractAnalyticsFacetCloudTest.java:56) > at > org.apache.solr.analytics.facet.QueryFacetCloudTest.beforeClass(QueryFacetCloudTest.java:44) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:874) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) > at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) > at > com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) > at > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) > at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) > at > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) > at > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > at > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) > at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) > at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) > at > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) > at > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) > at > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) > at > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) > at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) > at > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) > at java.lang.Thread.run(Thread.java:748) > Suppressed: java.lang.AssertionError > at > sun.reflect.generics.reflectiveObjects.WildcardTypeImpl.getUpperBoundASTs(WildcardTypeImpl.java:86) > at > sun.reflect.generics.reflectiveObjects.WildcardTypeImpl.getUpperBounds(WildcardTypeImpl.java:122) > at > sun.reflect.generics.reflectiveObjects.WildcardTypeImpl.toString(WildcardTypeImpl.java:190) > at java.lang.reflect.Type.getTypeName(Type.java:46) > at > sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl.toString(ParameterizedTypeImpl.java:234) > at java.lang.reflect.Type.getTypeName(Type.java:46) > at > java.lang.reflect.Method.specificToGenericStringHeader(Method.java:421) > at > java.lang.reflect.Executable.sharedToGenericString(Executable.java:163) > at java.lang.reflect.Method.toGenericString(Method.java:415) > at java.beans.MethodRef.set(MethodRef.java:46) > at > java.beans.MethodDescriptor.setMethod(MethodDescriptor.java:117) > at > java.beans.MethodDescriptor.<init>(MethodDescriptor.java:72) > at > java.beans.MethodDescriptor.<init>(MethodDescriptor.java:56) > at > java.beans.Introspector.getTargetMethodInfo(Introspector.java:1205) > at > java.beans.Introspector.getBeanInfo(Introspector.java:426) > at > java.beans.Introspector.getBeanInfo(Introspector.java:173) > at > java.beans.Introspector.getBeanInfo(Introspector.java:260) > at java.beans.Introspector.<init>(Introspector.java:407) > at > java.beans.Introspector.getBeanInfo(Introspector.java:173) > at > java.beans.Introspector.getBeanInfo(Introspector.java:260) > at java.beans.Introspector.<init>(Introspector.java:407) > at > java.beans.Introspector.getBeanInfo(Introspector.java:173) > at > java.beans.Introspector.getBeanInfo(Introspector.java:260) > at java.beans.Introspector.<init>(Introspector.java:407) > at > java.beans.Introspector.getBeanInfo(Introspector.java:173) > at > org.apache.solr.util.SolrPluginUtils.findSetter(SolrPluginUtils.java:1027) > at > org.apache.solr.util.SolrPluginUtils.invokeSetters(SolrPluginUtils.java:1011) > at > org.apache.solr.util.SolrPluginUtils.invokeSetters(SolrPluginUtils.java:1000) > > On Tue, Oct 17, 2017 at 12:13 PM, Peter Levart <peter.lev...@gmail.com> > wrote: > > Hi Dawid, > > The [2] mentions a thread which resulted in a patch by Martin Bucholtz for > JDK 9: > > https://bugs.openjdk.java.net/browse/JDK-8065172 > > ...but it seems this has not been backported to 8u (yet). The question is, > will there be any more 8u releases? Would you like this to be backported to > 8u? > > Regards, Peter > > > On 10/13/2017 09:53 AM, Dawid Weiss wrote: > > Hi all, > > We are observing very infrequent assertion errors originating in > getUpperBoundASTs, mostly during concurrent builds on our build > machine, when it's under a heavy load. This has been happening from > time to time with various Java versions; most recently with 1.8.0_131. > > I don't see anything in Jira about it, but even a quick Google search > yields some hits [1]. > > The stack trace starts with (I include the jackson stack frame which calls > it): > > java.lang.AssertionError: null > at > sun.reflect.generics.reflectiveObjects.WildcardTypeImpl.getUpperBoundASTs(WildcardTypeImpl.java:86) > ~[?:1.8.0_131] > at > sun.reflect.generics.reflectiveObjects.WildcardTypeImpl.getUpperBounds(WildcardTypeImpl.java:122) > ~[?:1.8.0_131] > at > com.fasterxml.jackson.databind.type.TypeFactory._fromWildcard(TypeFactory.java:1424) > ~[jackson-databind-2.8.2.jar:2.8.2] > > The problem cannot be easily reproduced, but I see a comment mentioned > on the core-libs-dev a while ago [2] by Joel Borggrén-Franck, so > perhaps his question is a valid one and worth investigating: > > Btw, has anyone seen the assert for upper/lower bounds == null fail in > the wild? > > Dawid > > [1] > https://www.google.com/search?q=getUpperBoundASTs+AssertionError&filter=0&biw=1279&bih=863 > (note the "[JENKINS] Lucene-olr-master-Linux" hit). > > [2] http://markmail.org/message/4phfnh7dj3qdlo6b > >
