groovy-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adrien Grand (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (GROOVY-7528) AssertionError at sun.reflect.generics.reflectiveObjects.WildcardTypeImpl.getLowerBoundASTs since Groovy 2.4.0 upgrade
Date Thu, 30 Jul 2015 14:29:04 GMT

    [ https://issues.apache.org/jira/browse/GROOVY-7528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14647677#comment-14647677
] 

Adrien Grand commented on GROOVY-7528:
--------------------------------------

Thanks Jochen for the insights, I will report if I manage to find the cause of the error.
I did some more research on my side and I was a bit too quick to correlate the errors with
the upgrade, it appears to be unrelated after all.

> AssertionError at sun.reflect.generics.reflectiveObjects.WildcardTypeImpl.getLowerBoundASTs
since Groovy 2.4.0 upgrade
> ----------------------------------------------------------------------------------------------------------------------
>
>                 Key: GROOVY-7528
>                 URL: https://issues.apache.org/jira/browse/GROOVY-7528
>             Project: Groovy
>          Issue Type: Bug
>    Affects Versions: 2.4.4
>            Reporter: Adrien Grand
>            Priority: Minor
>
> Since we upgraded from Grooy 2.4.0 to Groovy 2.4.4, we have been seeing occasional assertion
errors in {{sun.reflect.generics.reflectiveObjects.WildcardTypeImpl.getLowerBoundASTs}}.
> Here is the relevant stack trace:
> {noformat}
> java.lang.AssertionError
> 	at sun.reflect.generics.reflectiveObjects.WildcardTypeImpl.getLowerBoundASTs(WildcardTypeImpl.java:94)
> 	at sun.reflect.generics.reflectiveObjects.WildcardTypeImpl.getLowerBounds(WildcardTypeImpl.java:165)
> 	at com.sun.beans.TypeResolver.resolve(TypeResolver.java:176)
> 	at com.sun.beans.TypeResolver.resolve(TypeResolver.java:218)
> 	at com.sun.beans.TypeResolver.resolve(TypeResolver.java:169)
> 	at com.sun.beans.TypeResolver.resolveInClass(TypeResolver.java:81)
> 	at java.beans.FeatureDescriptor.getReturnType(FeatureDescriptor.java:370)
> 	at java.beans.Introspector.getTargetEventInfo(Introspector.java:996)
> 	at java.beans.Introspector.getBeanInfo(Introspector.java:417)
> 	at java.beans.Introspector.getBeanInfo(Introspector.java:163)
> 	at java.beans.Introspector.getBeanInfo(Introspector.java:250)
> 	at java.beans.Introspector.<init>(Introspector.java:397)
> 	at java.beans.Introspector.getBeanInfo(Introspector.java:163)
> 	at java.beans.Introspector.getBeanInfo(Introspector.java:250)
> 	at java.beans.Introspector.<init>(Introspector.java:397)
> 	at java.beans.Introspector.getBeanInfo(Introspector.java:163)
> 	at java.beans.Introspector.getBeanInfo(Introspector.java:250)
> 	at java.beans.Introspector.<init>(Introspector.java:397)
> 	at java.beans.Introspector.getBeanInfo(Introspector.java:163)
> 	at groovy.lang.MetaClassImpl$15.run(MetaClassImpl.java:3292)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at groovy.lang.MetaClassImpl.addProperties(MetaClassImpl.java:3290)
> 	at groovy.lang.MetaClassImpl.initialize(MetaClassImpl.java:3266)
> 	at org.codehaus.groovy.reflection.ClassInfo.getMetaClassUnderLock(ClassInfo.java:254)
> 	at org.codehaus.groovy.reflection.ClassInfo.getMetaClass(ClassInfo.java:285)
> 	at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.getMetaClass(MetaClassRegistryImpl.java:257)
> 	at org.codehaus.groovy.runtime.InvokerHelper.getMetaClass(InvokerHelper.java:875)
> 	at groovy.lang.GroovyObjectSupport.<init>(GroovyObjectSupport.java:34)
> 	at groovy.lang.Script.<init>(Script.java:42)
> 	at groovy.lang.Script.<init>(Script.java:39)
> 	at Script4.<init>(Script4.groovy)
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 	at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> 	at java.lang.Class.newInstance(Class.java:374)
> 	at org.elasticsearch.script.groovy.GroovyScriptEngineService.createScript(GroovyScriptEngineService.java:129)
> 	at org.elasticsearch.script.groovy.GroovyScriptEngineService.access$100(GroovyScriptEngineService.java:57)
> 	at org.elasticsearch.script.groovy.GroovyScriptEngineService$1.getLeafSearchScript(GroovyScriptEngineService.java:165)
> 	at org.elasticsearch.search.aggregations.support.ValuesSource$Numeric$WithScript.doubleValues(ValuesSource.java:314)
> 	at org.elasticsearch.search.aggregations.metrics.sum.SumAggregator.getLeafCollector(SumAggregator.java:74)
> 	at org.elasticsearch.search.aggregations.AggregatorBase.getLeafCollector(AggregatorBase.java:132)
> 	at org.elasticsearch.search.aggregations.AggregatorBase.getLeafCollector(AggregatorBase.java:131)
> 	at org.elasticsearch.search.aggregations.AggregatorBase.getLeafCollector(AggregatorBase.java:38)
> 	at org.apache.lucene.search.MultiCollector.getLeafCollector(MultiCollector.java:117)
> 	at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:762)
> 	at org.elasticsearch.search.internal.ContextIndexSearcher.search(ContextIndexSearcher.java:196)
> 	at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:485)
> 	at org.elasticsearch.search.internal.ContextIndexSearcher.search(ContextIndexSearcher.java:174)
> 	at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:694)
> 	at org.apache.lucene.search.IndexSearcher.searchAfter(IndexSearcher.java:410)
> 	at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:439)
> 	at org.elasticsearch.search.query.QueryPhase.execute(QueryPhase.java:151)
> {noformat}
> I found this old thread suggesting that the JDK code may not be correct and asking whether
someone saw this assertion trip in the wild: http://osdir.com/ml/core-libs-dev/2014-11/msg00337.html
so this might be a JDK bug rather than a Groovy bug. However we didn't see this assertion
error before we upgraded, so maybe there is a related Groovy change that made it more likely
to happen? Like the email thread mentions, one reason why few people hit this assertion error
might be that few people run with system assertions (-esa).
> We have only seen this assertion trip on a JDK 7 (not 8) but I couldn't find any information
related to fixing WildcardTypeImpl between JDK7 and JDK8, so I'm not totally sure the problem
is fixed if running with JDK 8. It might just be rarer.
> If you have confidence this is a JDK bug and not a Groovy bug, please feel free to close
it. Hopefully this will at least serve for future reference if anyone else hits the same issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message