groovy

java.lang.VerifyError with nested closures

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.0-JSR-5
  • Fix Version/s: 1.0-JSR-6
  • Component/s: None
  • Labels:
    None
  • Testcase included:
    yes
  • Number of attachments :
    0

Description

Following groovy code throws java.lang.Verify Error. If I change the second .each to a for loop or remove the if statement with .any, no error is thrown. This code was working with a JSR-05 snapshot from around JAN-30.

def census = []
census << [id:1, longTermClassId:1]
census << [id:4, longTermClassId:2]
def planClassMap = [1:[1], 2:[2]]
census.each { member->
planClassMap.each {pdId, classList -> /
if (classList.isEmpty() || classList.any{it == member.longTermClassId}) { classList << member }
}
}

ERROR:
Caught: java.lang.VerifyError: (class: LangVerifyError$_run_closure1_closure2, method: doCall signature: (Ljava/lang/Object;Ljava/la
ng/Object;)Ljava/lang/Object Accessing value from uninitialized register 4
at LangVerifyError$_run_closure1.doCall(LangVerifyError.groovy:6)
at LangVerifyError.run(LangVerifyError.groovy:5)
at LangVerifyError.main(LangVerifyError.groovy)

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
blackdrag blackdrag added a comment -

oh no! I hate VerifyErrors. They show I amde my work not good eneough
I will try to fix this asap. But it will have to wait some days, as I am currently ill and I surely will not do any bytecode things then. They are always a big strain. But it should be fixed until the end of the next week, I should be healthy enough then.

but... I still don't understand this error, I mean I have added safety mechanisms to avoid things like these... that's very strange...

Show
blackdrag blackdrag added a comment - oh no! I hate VerifyErrors. They show I amde my work not good eneough I will try to fix this asap. But it will have to wait some days, as I am currently ill and I surely will not do any bytecode things then. They are always a big strain. But it should be fixed until the end of the next week, I should be healthy enough then. but... I still don't understand this error, I mean I have added safety mechanisms to avoid things like these... that's very strange...
Hide
Permalink
blackdrag blackdrag added a comment -

In fact I found 2 errors, first there was a refernece created from a refernece because one closure parameter was stored as field. the second problem was the noninitilized register. The reason for that was that a boolean expression a || b may stop after evaluating b. This also means that if a register is used when creating the bytecode for b, that this register is not available to later code as initlized register. in the end it just increases the state stack in CompileStack, simple to solve.

So this should be fixed now

Show
blackdrag blackdrag added a comment - In fact I found 2 errors, first there was a refernece created from a refernece because one closure parameter was stored as field. the second problem was the noninitilized register. The reason for that was that a boolean expression a || b may stop after evaluating b. This also means that if a register is used when creating the bytecode for b, that this register is not available to later code as initlized register. in the end it just increases the state stack in CompileStack, simple to solve. So this should be fixed now
Hide
Permalink
Scott Hickey added a comment -

This has also fixed a StackOverflow error that we were having trouble creating a test case for. Thanks.

Show
Scott Hickey added a comment - This has also fixed a StackOverflow error that we were having trouble creating a test case for. Thanks.

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.