Maven build outputs NoClassDefFoundError stacktrace at the end of a build

[Thomas Ferris Nicolaisen]

Hi,

Since upgrading to the latest Hudson, all our maven builds have been outputting a stacktrace about "java.util.concurrent.ExecutionException: java.lang.NoClassDefFoundError: Could not initialize class hudson.model.Fingerprint" in the end. This output also ends up in the build-notification mails, which renderes their content pretty useless as real problems are hidden.

We are running Hudson 1.392 with master/slaves, all on Linux servers. Java 1.6.0_22, Maven 2.2.1. All slaves are launched using the ssh-slaves plugin, so they should have the correct slave.jar, I reckon.

This happens regardless of build result. Successful builds are still represented as blue.

Here's the stacktrace:

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 28 seconds
[INFO] Finished at: Thu Jan 06 17:20:29 CET 2011
[INFO] Final Memory: 28M/305M
[INFO] ------------------------------------------------------------------------
ERROR: Asynchronous execution failure
java.util.concurrent.ExecutionException: java.lang.NoClassDefFoundError: Could not initialize class hudson.model.Fingerprint
	at hudson.remoting.Channel$2.adapt(Channel.java:662)
	at hudson.remoting.Channel$2.adapt(Channel.java:657)
	at hudson.remoting.FutureAdapter.get(FutureAdapter.java:55)
	at hudson.maven.MavenBuilder.call(MavenBuilder.java:175)
	at hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:859)
	at hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:791)
	at hudson.remoting.UserRequest.perform(UserRequest.java:114)
	at hudson.remoting.UserRequest.perform(UserRequest.java:48)
	at hudson.remoting.Request$2.run(Request.java:270)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.NoClassDefFoundError: Could not initialize class hudson.model.Fingerprint
	at hudson.model.FingerprintMap.load(FingerprintMap.java:103)
	at hudson.model.FingerprintMap.load(FingerprintMap.java:46)
	at hudson.util.KeyedDataStorage.get(KeyedDataStorage.java:154)
	at hudson.model.FingerprintMap.get(FingerprintMap.java:88)
	at hudson.model.FingerprintMap.get(FingerprintMap.java:46)
	at hudson.util.KeyedDataStorage.getOrCreate(KeyedDataStorage.java:108)
	at hudson.model.FingerprintMap.getOrCreate(FingerprintMap.java:74)
	at hudson.maven.reporters.MavenFingerprinter$1.call(MavenFingerprinter.java:105)
	at hudson.maven.reporters.MavenFingerprinter$1.call(MavenFingerprinter.java:96)
	at hudson.maven.MavenBuild$ProxyImpl.execute(MavenBuild.java:350)
	at hudson.maven.MavenBuild$ProxyImpl2.execute(MavenBuild.java:423)
	at sun.reflect.GeneratedMethodAccessor229.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at hudson.model.Executor$1.call(Executor.java:429)
	at hudson.util.InterceptingProxy$1.invoke(InterceptingProxy.java:23)
	at $Proxy99.execute(Unknown Source)
	at hudson.maven.MavenBuildProxy$Filter$AsyncInvoker.call(MavenBuildProxy.java:263)
	... 9 more

Any pointers? I've seen similar issues were solved in the past by removing corrupted fingerprint files, but this seems different.

Thanks for your help,

-Thomas

[Thomas Ferris Nicolaisen]

I gather that this is not a general problem with Hudson 1.392, less other people would've been complaining about it. So far there's only one single related google-result.

I tried setting up the same build in a Hudson of the same version locally on my OS X laptop, also with master/slave setup. The problem does not occur there.

I've also tried running builds on the master node. Same problem occurs there, so I'm guessing it doesn't have anything to do with the remote builder.

I'm quickly running out of ideas, so I'm soon left with clearing out the hudson configuration and setting it up from scratch (a bit of work with over 60 jobs).. I'll start this after the weekend. It's probably about time after 1,5 years with regular upgrades and new plugins :) 

If anyone has any pointers or ideas before that, it would be highly appreciated though.

-Thomas

[Thomas Ferris Nicolaisen]

I managed to work around the issue:

1) Downgraded to 1.386.

2) In Manage Hudson I was prompted to remove stale configuration which could not be read (these were maven related). I did this (Dismiss..).

3) By now the problem was gone. I then upgraded to 1.393, and the problem did not re-appear.

I'll assume that this was an issue resolved to some stale configuration, and the steps above "ruffled" it up enough to make the problem go away. I would've debugged a bit more, but since our Hudson setup is fairly complex, and this was a bit of a freak occurrence, I don't think it would bring so much value.

[Lewis, Eric]

Sounds interesting! However, we run 1.362, so this would be an upgrade to 1.386. And then again upgrade? Or do you think a direct upgrade to 1.393 would solve the issue?

 

Best regards,

Eric

[Thomas Ferris Nicolaisen]

I'm not really sure what is the recommended upgrading practice, but I'd first make a back-up, and then try going straight for 1.393.

If you run into problems you can try backtracking to versions in between to find out which version introduced problems, and then look in the release notes for hints.