On 3/10/25 08:58, Richard Harker wrote:
Hi All.
We develop an OSGI Eclipse E4 based application which is written in a
combination of Java and Groovy. The application makes use of Groovy
templates dynamically loaded at runtime (to facilitate providing HTML
reports) and provides provision for the user to provide Groovy scripts
which are parsed and run by a GroovyShell at runtime.
a GRoovyShell... good that means you can set a CompilerConfiguration
[...]
We’ve been using Groovy for some years, and when we were on Groovy 2.5.x
did not see these issues at all. We see them on both Groovy 3.x and on
4.x, with them seemingly being more frequent on Groovy 4.x.
probably because Asm resolving is increased.
Has anyone else seen these types of issues? I’ve included two example
stack traces below. I’ve truncated each stack trace in the middle of the
repeating lines, so the email is not huge.
_Example stack trace 1 – from when we saw the Stack Overflow Exception
with latest Groovy (4.0.26), when the Groovy Shell parses a Groovy script._
[...]
at
org.codehaus.groovy.ast.decompiled.TypeSignatureParser.visitEnd(TypeSignatureParser.java:125)
at
groovyjarjarasm.asm.signature.SignatureReader.parseType(SignatureReader.java:206)
at
groovyjarjarasm.asm.signature.SignatureReader.parseType(SignatureReader.java:240)
at
groovyjarjarasm.asm.signature.SignatureReader.accept(SignatureReader.java:124)
at
org.codehaus.groovy.ast.decompiled.ClassSignatureParser.parseClassSignature(ClassSignatureParser.java:111)
at
org.codehaus.groovy.ast.decompiled.ClassSignatureParser.configureClass(ClassSignatureParser.java:35)
at
org.codehaus.groovy.ast.decompiled.DecompiledClassNode.lazyInitSupers(DecompiledClassNode.java:189)
at
org.codehaus.groovy.ast.decompiled.DecompiledClassNode.getGenericsTypes(DecompiledClassNode.java:148)
at
org.codehaus.groovy.ast.decompiled.TypeSignatureParser.visitEnd(TypeSignatureParser.java:125)
[...]
This seems to contain the loop. Assuming this is always the same
instance, then lazyInitSuper is supposed to be called only once early on
for the currently parsed class. If it really is the same instance then
this should be some kind of self reference. I also see generics involved
- potentially... So maybe something like
class Foo<T extends Foo>
or
class Foo implements Bar<Foo>
Important to note here... This class Foo is not a Groovy script and is
not loaded from the class path. Instead Groovy tries to load the zip file.
_Example 2 – The stack overflow seen with Groovy 3.0.23 when parsing one
of our TPL template files:_
[...]
at
org.codehaus.groovy.ast.decompiled.TypeSignatureParser.visitEnd(TypeSignatureParser.java:114)
at
groovyjarjarasm.asm.signature.SignatureReader.parseType(SignatureReader.java:206)
at
groovyjarjarasm.asm.signature.SignatureReader.parseType(SignatureReader.java:240)
at
groovyjarjarasm.asm.signature.SignatureReader.accept(SignatureReader.java:124)
at
org.codehaus.groovy.ast.decompiled.ClassSignatureParser.parseClassSignature(ClassSignatureParser.java:74)
at
org.codehaus.groovy.ast.decompiled.ClassSignatureParser.configureClass(ClassSignatureParser.java:32)
at
org.codehaus.groovy.ast.decompiled.DecompiledClassNode.lazyInitSupers(DecompiledClassNode.java:163)
at
org.codehaus.groovy.ast.decompiled.DecompiledClassNode.getGenericsTypes(DecompiledClassNode.java:128)
at
org.codehaus.groovy.ast.decompiled.TypeSignatureParser.visitEnd(TypeSignatureParser.java:114)
This loop looks quite similar.
Does anyone have any suggestions of what the cause of these issues may
be, or steps we could take to avoid the issues please?
If it’s relevant here, the JRE we’re currently using is Just J OpenJDK
JRE 21.0.5, though we’ve tried other versions of OpenJDK including 17.x
and still see the same issues.
what exactly I do not know. I assume Groovy is loading a class from a
zip file which contains a signature, which is no handled properly. As
written already I assume it is a self reference, where the class we
currently investigate (from the zip) appears in the signature itself.
But that is just a guess.
There might be a way around this. Since you use GroovyShell to compile
you can set (or already do so) a CompilerConfiguration. Could you please
set a configuration in which you get set the optimization option
"asmResolving". Something like this
CompilerConfiguration newConfig = new
CompilerConfiguration(CompilerConfiguration.DEFAULT)
Map optOptions = new
HashMap(CompilerConfiguration.DEFAULT.getOptimizationsOptions())
optOptions.set("asmResolving", false)
newConfig.setOptimizationOptions(optOptions)
groovyCompiler.setConfig....
This should avoid the loop since then the code causing this is no longer
in use. It may cuase a class not being found though. This option is no
officially supported option. WE have it mostly for testing and
debugging. This also means the name could change.
Thus, we also have to try finding the problem in the SignatureParsing
bye Jochen
