Quantcast

Bug? Inconsistent classfile encountered: The undefined type parameter V...

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bug? Inconsistent classfile encountered: The undefined type parameter V...

virtualeyes
Getting this on 1.8.2 in a Grails 2.0M2 project with STS 2.8M1

I see where the problem is but I do not know why an undefined Type error is thrown. Very odd, app runs but highly annoying having a groovy compiler error dialog popup on every single code change.

abstract class Controller {
    Class domain

    abstract def setup()
    def beforeInterceptor = {
        setup()
    }
}

class FooController extends Controller {
    def setup() {
        domain = Foo
    }
}

Here's the stacktrace:
BUG! exception in phase 'semantic analysis' in source unit '.../FooController.groovy' Pb(538) Inconsistent classfile encountered: The undefined type parameter V is referenced from within Controller._closure1
        at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:924)
        at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:589)
        at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:538)
        at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:168)
        at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.resolve(GroovyCompilationUnitDeclaration.java:1937)
        at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:820)
        at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137)
        at java.lang.Thread.run(Thread.java:662)
Caused by: org.eclipse.jdt.internal.compiler.problem.AbortCompilation: Pb(538) Inconsistent classfile encountered: The undefined type parameter V is referenced from within Controller._closure1
        at org.eclipse.jdt.internal.compiler.problem.ProblemHandler.handle(ProblemHandler.java:122)
        at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.handle(ProblemReporter.java:1992)
        at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.handle(ProblemReporter.java:2055)
        at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.undefinedTypeVariableSignature(ProblemReporter.java:6806)
        at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromTypeSignature(LookupEnvironment.java:1240)
        at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromVariantTypeSignature(LookupEnvironment.java:1308)
        at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeArgumentsFromSignature(LookupEnvironment.java:1095)
        at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromTypeSignature(LookupEnvironment.java:1257)
        at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.cachePartsFrom(BinaryTypeBinding.java:351)
        at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:694)
        at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:673)
        at org.eclipse.jdt.internal.compiler.Compiler.accept(Compiler.java:308)
        at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:114)
        at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:49)
        at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:126)
        at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.memberTypes(BinaryTypeBinding.java:1078)
        at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNode.mightHaveInners(JDTClassNode.java:105)
        at org.codehaus.groovy.control.ResolveVisitor.resolveNestedClass(ResolveVisitor.java:331)
        at org.codehaus.groovy.control.ResolveVisitor.resolve(ResolveVisitor.java:307)
        at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.resolve(JDTResolver.java:292)
        at org.codehaus.groovy.control.ResolveVisitor.resolve(ResolveVisitor.java:264)
        at org.codehaus.groovy.control.ResolveVisitor.resolveOrFail(ResolveVisitor.java:244)
        at org.codehaus.groovy.control.ResolveVisitor.resolveOrFail(ResolveVisitor.java:256)
        at org.codehaus.groovy.control.ResolveVisitor.visitProperty(ResolveVisitor.java:207)
        at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1163)
        at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:51)
        at org.codehaus.groovy.control.ResolveVisitor.visitClass(ResolveVisitor.java:1388)
        at org.codehaus.groovy.control.ResolveVisitor.startResolving(ResolveVisitor.java:165)
        at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.startResolving(JDTResolver.java:626)
        at org.codehaus.groovy.control.CompilationUnit$1.call(CompilationUnit.java:654)
        at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:915)
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug? Inconsistent classfile encountered: The undefined type parameter V...

Jochen Theodorou
Am 30.09.2011 09:20, schrieb virtualeyes:
> Getting this on 1.8.2 in a Grails 2.0M2 project with STS 2.8M1
>
> I see where the problem is but I do not know why an undefined Type error is
> thrown. Very odd, app runs but highly annoying having a groovy compiler
> error dialog popup on every single code change.

it is a bug, that we found appears as NPE in OpenJDK sometimes and is
ignored by the sun JDK. The JDT version is new to me. We did quite some
things to avoid that to happen in 1.8.3, Grails 2.0M3 with Groovy 1.8.3
will hopefully not have that problem anymore

bye blackdrag

--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug? Inconsistent classfile encountered: The undefined type parameter V...

virtualeyes
Yes, it is a mysterious bug, hard to pin down.

It first popped up about a month ago, and then inexplicably, after some reboots, changing this & that in the code (but in the end, maintaining same code I posted), went away. Now, same code that was error free, compiler error back again, really bizarre.

Should mention:
Fedora 14
Sun JDK 1.6.0_22
Groovy 1.8.2
Grails 2.0 M2
STS 2.8.0 M1

Maybe I should try latest 1.6 JDK? Not sure where to go from here, this error is tough to deal with, app runs fine, but IDE freaks out on every code change, serious drag...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug? Inconsistent classfile encountered: The undefined type parameter V...

Jochen Theodorou
Am 30.09.2011 10:03, schrieb virtualeyes:

> Yes, it is a mysterious bug, hard to pin down.
>
> It first popped up about a month ago, and then inexplicably, after some
> reboots, changing this&  that in the code (but in the end, maintaining same
> code I posted), went away. Now, same code that was error free, compiler
> error back again, really bizarre.
>
> Should mention:
> Fedora 14
> Sun JDK 1.6.0_22
> Groovy 1.8.2
> Grails 2.0 M2
> STS 2.8.0 M1
>
> Maybe I should try latest 1.6 JDK? Not sure where to go from here, this
> error is tough to deal with, app runs fine, but IDE freaks out on every code
> change, serious drag...

The bug in the bytecode is there all the time, only it is sometimes
checked for and sometimes not. It is not strictly forbidden by the JVM
spec, thus it is no error the VM has to check for. And compilers ignore
it most of the time as well - but not always.

bye blackdrag


--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Loading...