AssertionError in WildcardTypeImpl.getUpperBoundASTs
Dawid Weiss
dawid.weiss at gmail.com
Thu Oct 19 07:20:26 UTC 2017
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.levart at 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.levart at 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
>
>
More information about the core-libs-dev
mailing list