|
I get a null pointer exception on my jenkins slave when checking out code with the git client. It only happens on my slave running on ppc. It only happens after the first build. The first build is fine. If I delete all of the builds in the build history, it does happen. Thus, it appears to be related to calculating the differences between builds. I use the IBM JDK on x86 slaves without any problems. I've tried a couple versions of my local git, which I've compiled from source.
This ppc64 processor is big endian.
Checking out Revision 36e2d73db3a12422490470c4d651c94c9a053051 (refs/remotes/origin/develop)
> /home/wbuild/bin/git config core.sparsecheckout # timeout=10
> /home/wbuild/bin/git checkout -f 36e2d73db3a12422490470c4d651c94c9a053051
> /home/wbuild/bin/git rev-list 36e2d73db3a12422490470c4d651c94c9a053051 # timeout=10
No emails were triggered.
FATAL: null
java.lang.NullPointerException
at java.text.SimpleDateFormat.parse(SimpleDateFormat.java:1252)
at java.text.DateFormat.parse(DateFormat.java:346)
at hudson.plugins.git.GitChangeSet.getTimestamp(GitChangeSet.java:195)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
at groovy.lang.MetaClassImpl$GetBeanMethodMetaProperty.getProperty(MetaClassImpl.java:3500)
at org.codehaus.groovy.runtime.callsite.GetEffectivePojoPropertySite.getProperty(GetEffectivePojoPropertySite.java:61)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGetProperty(AbstractCallSite.java:227)
at Script1.run(Script1.groovy:9)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:650)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:636)
at hudson.plugins.groovy.SystemGroovy.perform(SystemGroovy.java:93)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:770)
at hudson.model.Build$BuildExecution.build(Build.java:199)
at hudson.model.Build$BuildExecution.doRun(Build.java:160)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:533)
at hudson.model.Run.execute(Run.java:1759)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:89)
at hudson.model.Executor.run(Executor.java:240)
http://www.ibm.com/developerworks/java/jdk/linux/download.html
The error seems to be propogating from GitChangeSet
@Override
public long getTimestamp() {
try {
return new SimpleDateFormat(ISO_8601).parse(getDate()).getTime();
} catch (ParseException e) {
return -1;
}
}
I suspect this snippet from GitChangeSet is providing a null value which gets passed into parse
public String getDate() {
return authorOrCommitter ? authorTime : committerTime;
}
if authorTime or committerTime were to get set, they would get set in GitChangeSet.parseCommit.
https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitChangeSet.java
As a work around, I wonder if getDate could check for a null. If authorTime or committerTime is a null and the other is not, then return the non-null value. If both are null then return 1/1/1970 which is another less disruptive way of indicating the date was not found since this corresponds to the epoch time, but would not cause the git plugin to fail the job. Perhaps some logging could also be inserted in these cases to enable us to get closer to the root cause of the problem, while allowing this work-around to the null pointer exception.
|
