ScalaTest and class unloading under sbt

[Bruce Mitchener]

Bill,

Following up on the older thread, I've put together a pretty small sample that can be used to demonstrate that classes aren't unloading.

The code is available at http://github.com/waywardmonkeys/scalatest_vs_class_unload

It happens with both a JUnitSuite and a FlatSpec.

As an aside, I had to import the scala.collection.mutable.Stack for the sample code on the home page (http://www.scalatest.org/) to work.

 - Bruce

[Bill Venners]

Hi Bruce,

Thanks. Do you just say >test in sbt a few times and you run out of
space? About how many times does it take?

Bill

> --
> You received this message because you are subscribed to the Google
> Groups "scalatest-users" group.
> To post to this group, send email to scalate...@googlegroups.com
> To unsubscribe from this group, send email to
> scalatest-use...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/scalatest-users?hl=en
> ScalaTest itself, and documentation, is available here:
> http://www.artima.com/scalatest

--
Bill Venners
Artima, Inc.
http://www.artima.com

[Bruce Mitchener]

In the real code, there are a bit over 200 tests, some of which are pretty weighty (using H2, etc).  I am able to run out of PermGen now in 2-3 runs with it set to 128M.

A quick check shows that if I set the PermGen to 3M on my laptop, I can run these tests once, but the second or third time locks up.

I'm using this version of Java on Mac OS X, Snow Leopard:

% java -version

java version "1.6.0_20"

Java(TM) SE Runtime Environment (build 1.6.0_20-b02-279-10M3065)

Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01-279, mixed mode)

 - Bruce

[Bill Venners]

Hi Bruce,

I cloned your Github repo and was unable as yet to reproduce the
problem. I repeatedly ran test but it never failed with an out of
memory error.

I did however fix the problem with -c runs, which was that I wasn't
shutting down the ExecutorService after a run, so eventually it just
ran out of threads. I'm not sure it was a class unloading problem that
I was seeing. It looked like a running-out-of-threads problem. That's
deployed as the same 1.2.1-SNAPSHOT, which still has the changes for
colorizing sbt output. This fix may solve Andreas Sewe's problem with
running concurrently, but he I think was also seeing memory problems
when running without -c. But I don't expect it to fix your problem,
because sbt does not ask ScalaTest to run tests concurrently.

I'll take a look again later today to see if I can reproduce the
problem you're seeing, but if you can think of any clues that might
help me reproduce it let me know.

Thanks.

Bill

On Tue, Aug 24, 2010 at 7:47 AM, Bruce Mitchener

[Bill Venners]

Hi Bruce,

Sorry, I forgot to post the details of how to grab the snapshot from
sbt. Just put this in your project file:

val scalaToolsSnapshots = ScalaToolsSnapshots
val scalatest = "org.scalatest" % "scalatest" % "1.2.1-SNAPSHOT"

Thanks.

Bill

[Bruce Mitchener]

On Mac OS X, all I have to do is run with this command line:

java -Xmx512M -XX:MaxPermSize=32M -verbosegc -XX:+TraceClassUnloading -jar `dirname $0`/sbt-launch-0.7.4.jar "$@"

With 1.2 (release), the JVM locks up in GC pain after 2-3 runs of 'test'.

With the current 1.2.1 snapshot, everything is fine and I can see things getting unloaded correctly and the JVM doesn't lock up.

What's the plan on a 1.2.1 release? :)

 - Bruce

[Bill Venners]

Hi Bruce,

I'm glad to hear it solves the problem, but don't understand why
concurrent running is being used when running through sbt. I'll
investigate further to make sure I understand how concurrency is
getting used. There may still be another bug lurking.

As far as 1.2.1, I didn't really have much on the list for that. Here's my list:

1. Merge in Kevin Wright's patch for FreshScala

Gets rid of checked in jar files

2. Color in sbt output. DONE

3. memory problem, -c, gui, ~test in sbt (Possibly DONE)

4. Add trait SeveredStackTraces

Almost done but needs documentation too. This trait will chop off the
top of a stack trace so the offending line of test code is easier to
find in IDEs, which don't yet directly support ScalaTest. Tools that
support ScalaTest directly can get stack depth info out of the
TestFailedException with no .

5. Implement the HTML reporter (I can move this to 1.2.2.)

6. Add trait BeforeAndAfterEachFunctions (Offers a more concise
(though non-stackable) way to do before and after style of fixture:

beforeEach { ... }
afterEach { ... }

The existing trait BeforeAndAfterEach is a bit more verbose because it
is method overriding, but the benefit is you can stack them--make
multiple traits that override the methods and calls super.beforeEach,
etc., so they can be mixed together in different combinations and
orders.

7. Update the version of EasyMock

EasyMock did a breaking change so you can't currently use ScalaTest
with the latest EasyMock. I'll probably upgrade EasyMockSugar to the
new EasyMock release, and add an EasyMock2Sugar that works with the
old release.

8. Remove some things that have been deprecated for two releases.

I'll try and get this out within the next week if possible.

Thanks.

Bill

On Wed, Aug 25, 2010 at 3:19 AM, Bruce Mitchener