JVM cannot find invoker
Jochen Theodorou
after some modifications to my code I suddenly got this exception:
> java.lang.InternalError: JVM cannot find invoker for (CompilationUnit,TreeNodeBuildingNodeOperation,int)Object
> at java.lang.invoke.Invokers.lookupInvoker(Invokers.java:91)
> at java.lang.invoke.Invokers.exactInvoker(Invokers.java:73)
> at java.lang.invoke.MethodHandles.exactInvoker(MethodHandles.java:1371)
> at java.lang.invoke.MethodHandleImpl.makeGuardWithTest(MethodHandleImpl.java:1072)
> at java.lang.invoke.MethodHandles.guardWithTest(MethodHandles.java:2162)
> at org.codehaus.groovy.vmplugin.v7.IndyInterface.setGuards(IndyInterface.java:424)
> at org.codehaus.groovy.vmplugin.v7.IndyInterface.selectMethod(IndyInterface.java:545)
I am not understanding the error and I hope somebody here can help me
with that. What does this mean? The guard I want to use here is a bound
method handle, with the resulting handle having no arguments. Is that
not allowed?
by Jochen
--
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
Jochen Theodorou
> Hi all,
>
> after some modifications to my code I suddenly got this exception:
>> java.lang.InternalError: JVM cannot find invoker for
>> (CompilationUnit,TreeNodeBuildingNodeOperation,int)Object
>> at java.lang.invoke.Invokers.lookupInvoker(Invokers.java:91)
>> at java.lang.invoke.Invokers.exactInvoker(Invokers.java:73)
>> at java.lang.invoke.MethodHandles.exactInvoker(MethodHandles.java:1371)
>> at
>> java.lang.invoke.MethodHandleImpl.makeGuardWithTest(MethodHandleImpl.java:1072)
>>
>> at java.lang.invoke.MethodHandles.guardWithTest(MethodHandles.java:2162)
>> at
>> org.codehaus.groovy.vmplugin.v7.IndyInterface.setGuards(IndyInterface.java:424)
>>
>> at
>> org.codehaus.groovy.vmplugin.v7.IndyInterface.selectMethod(IndyInterface.java:545)
>>
>
> I am not understanding the error and I hope somebody here can help me
> with that. What does this mean? The guard I want to use here is a bound
> method handle, with the resulting handle having no arguments. Is that
> not allowed?
I found a possible hint... TreeNodeBuildingNodeOperation is a private class.
What do I have to do again to get access to that class?
bye Jochen
Rémi Forax
> Am 31.01.2012 23:20, schrieb Jochen Theodorou:
>> Hi all,
>>
>> after some modifications to my code I suddenly got this exception:
>>> java.lang.InternalError: JVM cannot find invoker for
>>> (CompilationUnit,TreeNodeBuildingNodeOperation,int)Object
>>> at java.lang.invoke.Invokers.lookupInvoker(Invokers.java:91)
>>> at java.lang.invoke.Invokers.exactInvoker(Invokers.java:73)
>>> at java.lang.invoke.MethodHandles.exactInvoker(MethodHandles.java:1371)
>>> at
>>> java.lang.invoke.MethodHandleImpl.makeGuardWithTest(MethodHandleImpl.java:1072)
>>>
>>>
>>> at
>>> java.lang.invoke.MethodHandles.guardWithTest(MethodHandles.java:2162)
>>> at
>>> org.codehaus.groovy.vmplugin.v7.IndyInterface.setGuards(IndyInterface.java:424)
>>>
>>>
>>> at
>>> org.codehaus.groovy.vmplugin.v7.IndyInterface.selectMethod(IndyInterface.java:545)
>>>
>>>
>>
>> I am not understanding the error and I hope somebody here can help me
>> with that. What does this mean? The guard I want to use here is a bound
>> method handle, with the resulting handle having no arguments. Is that
>> not allowed?
Hi Jochen,
yes !
>
> I found a possible hint... TreeNodeBuildingNodeOperation is a private
> class.
>
> What do I have to do again to get access to that class?
>
> bye Jochen
>
I've tried to reproduce it, but fail.
Can you publish your code in a private repository ?
R�mi
Jochen Theodorou
> On 02/01/2012 01:23 AM, Jochen Theodorou wrote:
>> Am 31.01.2012 23:20, schrieb Jochen Theodorou:
>>> Hi all,
>>>
>>> after some modifications to my code I suddenly got this exception:
>>>> java.lang.InternalError: JVM cannot find invoker for
>>>> (CompilationUnit,TreeNodeBuildingNodeOperation,int)Object
>>>> at java.lang.invoke.Invokers.lookupInvoker(Invokers.java:91)
>>>> at java.lang.invoke.Invokers.exactInvoker(Invokers.java:73)
>>>> at java.lang.invoke.MethodHandles.exactInvoker(MethodHandles.java:1371)
>>>> at java.lang.invoke.MethodHandleImpl.makeGuardWithTest(MethodHandleImpl.java:1072)
>>>> at java.lang.invoke.MethodHandles.guardWithTest(MethodHandles.java:2162)
>>>> at org.codehaus.groovy.vmplugin.v7.IndyInterface.setGuards(IndyInterface.java:424)
>>>> at org.codehaus.groovy.vmplugin.v7.IndyInterface.selectMethod(IndyInterface.java:545)
>>>
>>> I am not understanding the error and I hope somebody here can help me
>>> with that. What does this mean? The guard I want to use here is a bound
>>> method handle, with the resulting handle having no arguments. Is that
>>> not allowed?
>
> Hi Jochen,
>
> yes !
it is not allowed? uh. Even if I add to drop the arguments to create
handle that can take all arguments I land in the same error...
>> I found a possible hint... TreeNodeBuildingNodeOperation is a private
>> class.
>>
>> What do I have to do again to get access to that class?
>>
>> bye Jochen
>>
>
> I've tried to reproduce it, but fail.
>
> Can you publish your code in a private repository ?
You can use https://github.com/groovy/groovy-core/tree/indy
Not exactly private, but it doesn't matter. The page may not show the
current state, but a git checkout should. The last change I did to the
indy code was to remove the dummy receiver. Before I was already using
this zero argument test and didn't get this error. You can easily see
this by running "ant clean test" with the current head see about 20
times the error above. Or with that last commit not used and those tests
all passing.
I am a bit puzzled about this message in general... should an
InternalError even be thrown normally? Isn't that hinting a bug? btw I
use jdk7u2
Rémi Forax
sorry, yes => it's obviously allowed.
>
>>> I found a possible hint... TreeNodeBuildingNodeOperation is a private
>>> class.
>>>
>>> What do I have to do again to get access to that class?
>>>
>>> bye Jochen
>>>
>>
>> I've tried to reproduce it, but fail.
>>
>> Can you publish your code in a private repository ?
>
> You can use https://github.com/groovy/groovy-core/tree/indy
> Not exactly private, but it doesn't matter. The page may not show the
> current state, but a git checkout should. The last change I did to the
> indy code was to remove the dummy receiver. Before I was already using
> this zero argument test and didn't get this error. You can easily see
> this by running "ant clean test" with the current head see about 20
> times the error above. Or with that last commit not used and those
> tests all passing.
>
> I am a bit puzzled about this message in general... should an
> InternalError even be thrown normally? Isn't that hinting a bug? btw I
> use jdk7u2
yes, you hit a bug.
>
> bye Jochen
>
R�mi
Rémi Forax
This is weird,
All tests but one in UberTestCaseJavaSourceGroovyPackagesSecurity pass
for me,
with jdk7u2 and jdk8b23.
>
> I am a bit puzzled about this message in general... should an
> InternalError even be thrown normally? Isn't that hinting a bug? btw I
> use jdk7u2
>
> bye Jochen
>
cheers,
R�mi
Jochen Theodorou
[...]
> This is weird,
> All tests but one in UberTestCaseJavaSourceGroovyPackagesSecurity pass
> for me,
> with jdk7u2 and jdk8b23.
ah great... so not only did I hit a bug, it does also only manifest
here. I am using the linux 64 bit version, what do you use?
Jochen Theodorou
[...]
> All tests but one in UberTestCaseJavaSourceGroovyPackagesSecurity pass
> for me,
> with jdk7u2 and jdk8b23.
I guess I will try jdk8b23 next and hope the bug vanishes over time
somehow.... But if that also does not work...
I removed the test, but all I get is the same error with the next test
being applied. Remi, you have any idea as of why this is failing and how
I can get around it?
Jochen Theodorou
> Am 01.02.2012 12:38, schrieb R�mi Forax:
> [...]
>> This is weird,
>> All tests but one in UberTestCaseJavaSourceGroovyPackagesSecurity pass
>> for me,
>> with jdk7u2 and jdk8b23.
>
> I guess I will try jdk8b23 next and hope the bug vanishes over time
> somehow.... But if that also does not work...
so... now I am stuck... jdk8b23 has the problem too and I have Cedric
confirming the same bug on his machine for jdk7u2 and for 1.7.0_147-icedtea
Looks like I will have to fill my very first JVM bug report