Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extractor issue - compiler crashes or at runtime get java.lang.VerifyError #4415

Closed
scabug opened this issue Mar 30, 2011 · 6 comments
Closed
Assignees
Labels
Milestone

Comments

@scabug
Copy link

scabug commented Mar 30, 2011

Running some pattern matchers causes either a compiler crash or at runtime a java.lang.!VerifyError.[[BR]]
Which happens depends on exact structure of pattern match (see below code, or self-contained test file attached).
[[BR]]

/**
 * Demonstration of issue with Extractors. If lines 15/16 are not present, get at runtime:
 *
 * Exception in thread "main" java.lang.VerifyError: (class: ExtractorIssue$$, method: convert signature: (LTopProperty;)LMyProp;) Accessing value from uninitialized register 5
 *	at ExtractorIssue.main(ExtractorIssue.scala)
 *	at com.intellij.rt.execution.application.AppMain.main(AppMain.java:115)]
 *
 * If lines 15/16 are present, the compiler crashes:
 *
 * fatal error (server aborted): not enough arguments for method body%3: (val p: MyProp[java.lang.String])MyProp[_33].
 * Unspecified value parameter p.
 */
object ExtractorIssue {

  def main(args: Array[String]) {
    convert(new SubclassProperty)
  }

  def convert(prop: TopProperty): MyProp[_] = {
    prop match {

        ///////////////////////////////////////////////////////////////////////////////////////////////////////////////
        //case SubclassSecondMatch(p) => p // if these lines are present, the compiler crashes. If commented, unsafe byte
        //case SecondMatch(p) => p         // byte code is generated, which causes a java.lang.VerifyError at runtime
        ///////////////////////////////////////////////////////////////////////////////////////////////////////////////

        case SubclassMatch(p) => p
        case StandardMatch(p) => p
    }
  }
}

class TopProperty

class StandardProperty extends TopProperty
class SubclassProperty extends StandardProperty

class SecondProperty extends TopProperty
class SubclassSecondProperty extends StandardProperty

trait MyProp[T]
case class MyPropImpl[T] extends MyProp[T]

object SubclassMatch {

  def unapply(prop: SubclassProperty) : Option[MyProp[String]] = {
    Some(new MyPropImpl)
  }

  def apply(prop: MyProp[String]) : SubclassProperty = {
    new SubclassProperty()
  }
}

object StandardMatch {

  def unapply(prop: StandardProperty) : Option[MyProp[String]] = {
    Some(new MyPropImpl)
  }

  def apply(prop: MyProp[String]) : StandardProperty = {
    new StandardProperty()
  }
}

object SubclassSecondMatch {

  def unapply(prop: SubclassSecondProperty) : Option[MyProp[BigInt]] = {
    Some(new MyPropImpl)
  }

  def apply(prop: MyProp[String]) : SubclassSecondProperty = {
    new SubclassSecondProperty()
  }
}

object SecondMatch {

  def unapply(prop: SecondProperty) : Option[MyProp[BigInt]] = {
    Some(new MyPropImpl)
  }

  def apply(prop: MyProp[String]) : SecondProperty = {
    new SecondProperty()
  }
}

=== What is the expected behavior? ===

Should pattern match.

=== What do you see instead? ===

Crash, of compiler or runtime.

=== Additional information ===
This seems similar to, but also possibly distinct from the following two issues:

https://lampsvn.epfl.ch/trac/scala/ticket/3702 [[BR]]
https://lampsvn.epfl.ch/trac/scala/ticket/3972 [[BR]]

=== What versions of the following are you using? ===

  • Scala: 2.8.1, 2.9RC1
  • Java: sunjdk\1.6.0_21
  • Operating system: Windows XP
@scabug
Copy link
Author

scabug commented Mar 30, 2011

Imported From: https://issues.scala-lang.org/browse/SI-4415?orig=1
Reporter: jhodkinson
Attachments:

@scabug
Copy link
Author

scabug commented Jun 30, 2011

jhodkinson said:
Any update on this issue?

@scabug
Copy link
Author

scabug commented Jan 19, 2012

@szeiger said:
With -Yvirtpatmat in master (scala-2.10.0.rdev-4208-2012-01-19-g58cb15c) the VerifyError is gone. The compiler crash still occurs with both, the old pattern matcher and the virtualized pattern matcher.

@scabug
Copy link
Author

scabug commented Jan 24, 2012

@paulp said:
I find no crash with 2.10.0.rdev-4232-2012-01-22-g9a20086 under -Yvirtpatmat. I doubt it was fixed in that short span. Can you reconfirm it, and post details if it's reproducible? (I did uncomment the lines which are supposed to lead to a crash, and do crash without -Yvirtpatmat.)

@scabug
Copy link
Author

scabug commented Jan 24, 2012

@szeiger said:
Sorry, I can't reproduce this anymore. It's compiling just fine under 4208 and 4234 with -Yvirtpatmat. Leaving this ticket open for now because it's not fixed in the old patmat which is still the default.

@scabug
Copy link
Author

scabug commented May 4, 2012

@paulp said:
virtpatmat saves day, test in 8bc8b83f0b .

@scabug scabug closed this as completed May 4, 2012
@scabug scabug added the patmat label Apr 7, 2017
@scabug scabug added this to the 2.10.0 milestone Apr 7, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants