AbstractMethodError under 2.9.1

31 views
Skip to first unread message

Scott Morrison

unread,
Mar 29, 2012, 12:35:40 AM3/29/12
to scala...@googlegroups.com, categor...@googlegroups.com
I seem to be able to reliably produce an AbstractMethodError under 2.9.1. I'm not doing anything silly; compilation is done in a single pass by SBT. My understanding is that this probably indicates an actual compiler problem, hiding somewhere.

Unfortunately I don't have a minimal example, but I do have an easily reproducible example.

cd categoricaldata
./sbt test

works just fine. However,

cd categoricaldata
./sbt test


[error] Could not run test net.categoricaldata.category.LeftPushforwardTest: java.lang.AbstractMethodError 

I did make some attempt to understand the origins of this, but I found it rather hard to debug in the presence of AbstractMethodErrors! I suspect that somehow the problem arises from a hack using DummyImplicit, c.f.

  final def apply(o: source.O): target.O = onObjects(o)
  // the dummy implicit argument is a hack to allow overloading of apply
  final def apply(m: source.M)(implicit d: DummyImplicit): target.M = onMorphisms(m)

in <https://bitbucket.org/categoricaldata/categoricaldata/src/7a116d87a867/src/main/scala/net/categoricaldata/category/Functor.scala>. At this point I know how to work around these AbstractMethodErrors (avoid the use of these apply methods, and always use onObjects or onMorphisms instead). But I really suspect that there's a compiler problem lurking here, so I thought I should let people know here!

best regards,
Scott Morrison 
 

Naftoli Gugenheim

unread,
Mar 29, 2012, 1:14:34 AM3/29/12
to Scott Morrison, scala...@googlegroups.com, categor...@googlegroups.com
Which method is it saying is abstract?

Scott Morrison

unread,
Mar 29, 2012, 2:34:00 AM3/29/12
to scala...@googlegroups.com, Scott Morrison, categor...@googlegroups.com
That's a strange thing --- it doesn't tell me!

Here's the top of a stack trace:

java.lang.AbstractMethodError
at net.categoricaldata.category.Functor$withLocallyFinitelyGeneratedSource$anonfun$1.apply(Functor.scala:52)
at scala.collection.TraversableLike$anonfun$map$1.apply(TraversableLike.scala:194)
at scala.collection.TraversableLike$anonfun$map$1.apply(TraversableLike.scala:194)
at scala.collection.LinearSeqOptimized$class.foreach(LinearSeqOptimized.scala:59)
at scala.collection.immutable.List.foreach(List.scala:45)
at scala.collection.TraversableLike$class.map(TraversableLike.scala:194)
at scala.collection.immutable.List.map(List.scala:45)
at net.categoricaldata.category.Functor$withLocallyFinitelyGeneratedSource$class.onMorphisms(Functor.scala:52)
at net.categoricaldata.category.functor.withFinitelyGeneratedSource.withFinitelyGeneratedTarget$CosliceFunctor$CosliceFunctorOver$anon$2.onMorphisms(withFinitelyGeneratedTarget.scala:54)
at net.categoricaldata.category.functor.withFinitelyGeneratedSource.withFinitelyGeneratedTarget$CosliceFunctor$CosliceFunctorOver$anon$2.onMorphisms(withFinitelyGeneratedTarget.scala:54)
at net.categoricaldata.category.functor.withSmallSource.withSmallTarget$Pullback$anon$1.onMorphisms(withSmallTarget.scala:37)
at net.categoricaldata.category.functor.withSmallSource.withSmallTarget$Pullback$anon$1.onMorphisms(withSmallTarget.scala:35)
at net.categoricaldata.category.FinitelyGeneratedCategory$StandardFunctorsToSet$anon$1$anon$2.onGenerators(FinitelyGeneratedCategory.scala:444)
at net.categoricaldata.category.FinitelyGeneratedCategory$StandardFunctorsToSet$anon$1$anon$2.onGenerators(FinitelyGeneratedCategory.scala:441)
at net.categoricaldata.category.Functor$withLocallyFinitelyGeneratedSource$anonfun$1.apply(Functor.scala:52)

and I *suspect* that this means that in

  trait withLocallyFinitelyGeneratedSource extends withSmallSource { functor =>
    override val source: LocallyFinitelyGeneratedCategory
    def onGenerators(g: source.G): target.M
    override def onMorphisms(m: source.M) = {
      val start = onObjects(source.source(m))
      val morphisms = for (g <- m.representative.morphisms) yield onGenerators(g)
      target.compose(start, morphisms)
    }
  }


best regards,
Scott Morrison

Naftoli Gugenheim

unread,
Mar 29, 2012, 3:33:36 AM3/29/12
to Scott Morrison, scala...@googlegroups.com, categor...@googlegroups.com
Where is withLocallyFinitelyGeneratedSource implemented? Can you javap or scalap the relevant class files --- the ones that are actually being used in the runtime environment --- and check that everything looks right?

Scott Morrison

unread,
Apr 4, 2012, 8:33:57 PM4/4/12
to Naftoli Gugenheim, scala...@googlegroups.com, categor...@googlegroups.com
Hi,

I've had a chance to dig deeper. Downloading and running the tests

hg clone -r cc4c0dc0a2d9 https://bitbucket.org/categoricaldata/categoricaldata
cd categoricaldata
./sbt test

produces an AbstractMethodError in withLocallyFinitelyGeneratedSource, which is implemented in net.categoricaldata.category.functor.withFinitelyGeneratedSource.withFinitelyGeneratedTarget$CosliceFunctor$CosliceFunctorOver$F. The output of scalap

scalap scalap -cp target/scala-2.9.2-RC2/classes/  "net.categoricaldata.category.functor.withFinitelyGeneratedSource.withFinitelyGeneratedTarget\$CosliceFunctor\$CosliceFunctorOver\$F"

on this is here at pastebin.

Now, if we just add some whitespace to the critical file, via

echo >> src/main/scala/net/categoricaldata/category/functor/withFinitelyGeneratedSource/withFinitelyGeneratedTarget.scala 

and run the tests again

./sbt test

we no longer get an AbstractMethodError (the tests fail some other way, that's fine for now). The new output from 

scalap scalap -cp target/scala-2.9.2-RC2/classes/  "net.categoricaldata.category.functor.withFinitelyGeneratedSource.withFinitelyGeneratedTarget\$CosliceFunctor\$CosliceFunctorOver\$F"

is over here at pastebin. Notice the difference between the two outputs of scalap. In the version that works, there's just a single extra line:

  def onGenerators(scala.Any): scala.Any;

I'm not sure what's going on here, but I'm happy to try to conduct further experiments if anyone can advise me. It's starting to look as if the problem may be inside sbt rather than the compiler, because a second round of compilation tweaking whitespace causes the problem to vanish, but I'm not really sure how to diagnose this.

Further advice very much appreciated!

best regards,
Scott Morrison
Reply all
Reply to author
Forward
0 new messages