Failing Guice builds

[Tim Boudreau]

So I've got these two Jenkins build servers, and since I was using Guice 3.1.0-SNAPSHOT for a long time, both of them build Guice using Maven. One is the build server I've been using for a while, and the other is the server I'm going to switch to, on a box I own. Jenkins is configured identically on both - the configuration was copied from one to the other. Both are running on Oracle's JDK 1.7 build 25, with Maven 3.0.5.

Tests pass on one, and fail on the other. The only difference between the two is the OS - the builds pass on Linux, but fail on SmartOS (OpenSolaris variant from Joyent). Is there a known problem with com.google.inject.assistedinject.ExtensionSpiTest.testSpiOnElement or com.google.inject.assistedinject.ExtensionSpiTest.testSpiOnVisitor?

Here is the build passing on Linux:

http://timboudreau.com/builds/job/Guice%203/

and identically configured but failing on SmartOS:

http://builds.fcat.dyndns.org/builds/job/Guice%203/

http://builds.fcat.dyndns.org/builds/job/Guice%203/com.google.inject.extensions$guice-assistedinject/27/testReport/junit/com.google.inject.assistedinject/ExtensionSpiTest/testSpiOnElements_on_instance_testSpiOnElements/

http://builds.fcat.dyndns.org/builds/job/Guice%203/com.google.inject.extensions$guice-assistedinject/27/testReport/junit/com.google.inject.assistedinject/ExtensionSpiTest/testSpiOnVisitor_on_instance_testSpiOnVisitor/

Known problem? Any ideas?

-Tim

[Sam Berlin]

Not a known problem -- we haven't had any issue with the tests.  The links you pasted don't seem to give any test results (they give 404s).  Could you paste the stack trace / failure here?

Thanks!

 sam

--
You received this message because you are subscribed to the Google Groups "google-guice" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-guice...@googlegroups.com.
To post to this group, send email to google...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-guice.
For more options, visit https://groups.google.com/groups/opt_out.

[Tim Boudreau]

On Sat, Sep 28, 2013 at 3:18 PM, Sam Berlin <sbe...@gmail.com> wrote:

Not a known problem -- we haven't had any issue with the tests.  The links you pasted don't seem to give any test results (they give 404s).  Could you paste the stack trace / failure here?

Hrm...you should be able to get there from http://builds.timboudreau.com/builds/job/Guice%203/ - click one of the build links on the left, then "Show all failed tests".

Anyway, here you go:

Error Message

expected:<...AStrangeCatAsAnimal> but was:<...Cat>

Stacktrace

junit.framework.ComparisonFailure: expected:<...AStrangeCatAsAnimal> but was:<...Cat>
	at junit.framework.Assert.assertEquals(Assert.java:81)
	at junit.framework.Assert.assertEquals(Assert.java:87)
	at com.google.inject.assistedinject.ExtensionSpiTest.validateAssistedMethod(ExtensionSpiTest.java:134)
	at com.google.inject.assistedinject.ExtensionSpiTest.validateCreateAStrangeCatAsAnimal(ExtensionSpiTest.java:94)
	at com.google.inject.assistedinject.ExtensionSpiTest.validateVisitor(ExtensionSpiTest.java:83)
	at com.google.inject.assistedinject.ExtensionSpiTest.testSpiOnVisitor(ExtensionSpiTest.java:70)

----------------

Error Message

expected:<...AStrangeCatAsAnimal> but was:<...Cat>

Stacktrace

junit.framework.ComparisonFailure: expected:<...AStrangeCatAsAnimal> but was:<...Cat>
	at junit.framework.Assert.assertEquals(Assert.java:81)
	at junit.framework.Assert.assertEquals(Assert.java:87)
	at com.google.inject.assistedinject.ExtensionSpiTest.validateAssistedMethod(ExtensionSpiTest.java:134)
	at com.google.inject.assistedinject.ExtensionSpiTest.validateCreateAStrangeCatAsAnimal(ExtensionSpiTest.java:94)
	at com.google.inject.assistedinject.ExtensionSpiTest.validateVisitor(ExtensionSpiTest.java:83)
	at com.google.inject.assistedinject.ExtensionSpiTest.testSpiOnElements(ExtensionSpiTest.java:60)

[Sam Berlin]

Looks like the test is implicitly dependent on the iteration order of ImmutableMap.  It's asserting each of the assisted methods in order, and the assisted methods are coming from assistDataByMethod.values(), which is an ImmutableMap<Method, AssistData>.  The Map is an ImmutableMap, so the iteration order is the insertion order, and the insertion order is dependent on factoryRawType.getMethods() (where factoryRawType here would be AnimalFactory.class).

I'm kinda surprised the test isn't more flaky in general.  Since JDK7, the order of getMethods() has more to do with the way memory is laid out then anything else, which'd make sense that it'd be different on different platforms.  The test should probably change to sort the values before testing them, since the iteration order is undefined.

sam

--

[Tim Boudreau]

Glad it's just a test bug - better than a real one.

Should I expect a fix will be committed in the next week or so, or should I just set my build to skip tests for the forseeable future?  I'm happy to leave the build failing if that will help verify the fix.

-Tim

[Sam Berlin]

I'll try to find some time to fix it & push out the fix this week.  You're very welcome to submit a patch also. :-)

 sam

[Christian Gruber]

This quarter I'm hoping to get several Google open-source java projects
onto an external continuous integration (of some variety, even if it's
just duck-taped) but the net effect is that I hope we will have Guice's
tests running on more than one JVM, and more than one platform. That
should surface these. I'm frankly surprised this hasn't gone flakey in
our internal testing environment - a lot of other projects that had
tests based on method order failed pretty quickly after we switched to
JDK7. :/

Thanks for catching this.

Christian.

Christian Gruber :: Google, Inc. :: Java Core Libraries :: Dependency
Injection
email: cgr...@google.com :::: mobile: +1 (646) 807-9839

[Tim Boudreau]

On Monday, September 30, 2013 12:28:37 PM UTC-4, Christian Gruber wrote:

This quarter I'm hoping to get several Google open-source java projects
onto an external continuous integration (of some variety, even if it's
just duck-taped) but the net effect is that I hope we will have Guice's
tests running on more than one JVM, and more than one platform.

Well, in the meantime I'm happy to provide this build of Guice on a Solaris variant: http://timboudreau.com/builds/job/Guice%203/

Any chance the tests will be fixed soon?  It's not the end of the world, but I don't really like seeing failing builds on my dashboard ;-)

-Tim

[Tim Boudreau]

I am looking at this lovely sea of little bluish-green balls, indicating builds that passed all their tests:  http://timboudreau.com/builds/

But there is this one sad, lonely little yellow ball indicating failing tests.  And it is Guice.  With it is a sad little phrase, "Last stable build (#15), 5 mo 1 day ago".

Poor Guice.  Don't its developers love it anymore?  Are they having too much fun with their new children to care for to their almost-grown ones?

And in the holiday season, even!  Wouldn't they like to give poor Guice a christmas present of a bright, shiny, passes-on-all-platforms, doesn't assume test-method-execution-order ExtensionSpiTest?

-Tim

[Sam Berlin]

Sorry, Tim. It's 100% consistently stable on our builds internally, day in and day out... So it hasn't really bumped up on our radar of things to do. When there's some time, I'll try to fix it. Again, if you submit a patch it'll be a lot easier.

Thanks

sam

[Christian Gruber]

Wait - what build is failing? We run a clean build before we push git
refs. Hmm. I'm confused. I'll take a look and see if I can figure it
out.

c.