Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-7699

JDepend plugin breaks "build.xml" which eventually removes build from history

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Blocker
    • Resolution: Fixed
    • Component/s: core
    • Labels:
      None
    • Environment:
      Linux F12 64 bit
    • Similar Issues:

      Description

      From Hudson 1.374, JDepend plugin breaks generation of "build.xml" for every build which eventually makes build unusable and it gets removed from history when hudson service is restarted/reloaded.

      We use hudson to do CI of our PHP based projects (I am not java guy, so forgive me if I could not provide exact details.). We use JDepend 1.2.2 plugin to generate JDepend report for hudson from generated jdepend.xml which gets created during the build. We generate that file using Phing (which has a task to generate JDepend file.) + PHPDepend softwares.

      From version 1.374, JDepend plugin has stopped to generate report from file and gives following errors in hudson's log file:

      =========================================================================
      Oct 7, 2010 2:35:45 PM hudson.model.Executor run
      SEVERE: Executor throw an exception unexpectedly
      java.lang.RuntimeException: Failed to serialize hudson.model.Actionable#actions for class hudson.model.FreeStyleBuild
      at hudson.util.RobustReflectionConverter$2.writeField(RobustReflectionConverter.java:167)
      at hudson.util.RobustReflectionConverter$2.visit(RobustReflectionConverter.java:135)
      at com.thoughtworks.xstream.converters.reflection.PureJavaReflectionProvider.visitSerializableFields(PureJavaReflectionProvider.java:130)
      at hudson.util.RobustReflectionConverter.doMarshal(RobustReflectionConverter.java:120)
      at hudson.util.RobustReflectionConverter.marshal(RobustReflectionConverter.java:94)
      at com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:68)
      at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:78)
      at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:63)
      at com.thoughtworks.xstream.core.TreeMarshaller.start(TreeMarshaller.java:98)
      at com.thoughtworks.xstream.core.AbstractTreeMarshallingStrategy.marshal(AbstractTreeMarshallingStrategy.java:38)
      at com.thoughtworks.xstream.XStream.marshal(XStream.java:840)
      at com.thoughtworks.xstream.XStream.marshal(XStream.java:829)
      at com.thoughtworks.xstream.XStream.toXML(XStream.java:804)
      at hudson.XmlFile.write(XmlFile.java:165)
      at hudson.model.Run.save(Run.java:1402)
      at hudson.model.Run.run(Run.java:1328)
      at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
      at hudson.model.ResourceController.execute(ResourceController.java:88)
      at hudson.model.Executor.run(Executor.java:129)
      Caused by: java.lang.RuntimeException: Failed to serialize hudson.plugins.jdepend.JDependBuildAction#jDependParser for class hudson.plugins.jdepend.JDependBuildAction
      at hudson.util.RobustReflectionConverter$2.writeField(RobustReflectionConverter.java:167)
      at hudson.util.RobustReflectionConverter$2.visit(RobustReflectionConverter.java:135)
      at com.thoughtworks.xstream.converters.reflection.PureJavaReflectionProvider.visitSerializableFields(PureJavaReflectionProvider.java:130)
      at hudson.util.RobustReflectionConverter.doMarshal(RobustReflectionConverter.java:120)
      at hudson.util.RobustReflectionConverter.marshal(RobustReflectionConverter.java:94)
      at com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:68)
      at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:78)
      at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:63)
      at com.thoughtworks.xstream.converters.collections.AbstractCollectionConverter.writeItem(AbstractCollectionConverter.java:64)
      at com.thoughtworks.xstream.converters.collections.CollectionConverter.marshal(CollectionConverter.java:55)
      at com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:68)
      at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:78)
      at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:63)
      at hudson.util.RobustReflectionConverter.marshallField(RobustReflectionConverter.java:175)
      at hudson.util.RobustReflectionConverter$2.writeField(RobustReflectionConverter.java:163)
      ... 18 more
      Caused by: java.lang.RuntimeException: Failed to serialize org.codehaus.mojo.jdepend.JDependXMLReportParser#stack for class hudson.plugins.jdepend.JDependParser
      at hudson.util.RobustReflectionConverter$2.writeField(RobustReflectionConverter.java:167)
      at hudson.util.RobustReflectionConverter$2.visit(RobustReflectionConverter.java:135)
      at com.thoughtworks.xstream.converters.reflection.PureJavaReflectionProvider.visitSerializableFields(PureJavaReflectionProvider.java:130)
      at hudson.util.RobustReflectionConverter.doMarshal(RobustReflectionConverter.java:120)
      at hudson.util.RobustReflectionConverter.marshal(RobustReflectionConverter.java:94)
      at com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:68)
      at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:78)
      at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:63)
      at hudson.util.RobustReflectionConverter.marshallField(RobustReflectionConverter.java:175)
      at hudson.util.RobustReflectionConverter$2.writeField(RobustReflectionConverter.java:163)
      ... 32 more
      Caused by: com.thoughtworks.xstream.converters.ConversionException: Could not call java.util.Stack.writeObject() : null
      ---- Debugging information ----
      message : Could not call java.util.Stack.writeObject()
      cause-exception : java.lang.NullPointerException
      cause-message : null
      -------------------------------
      at com.thoughtworks.xstream.converters.reflection.SerializationMethodInvoker.callWriteObject(SerializationMethodInvoker.java:104)
      at com.thoughtworks.xstream.converters.reflection.SerializableConverter.doMarshal(SerializableConverter.java:215)
      at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.marshal(AbstractReflectionConverter.java:58)
      at com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:68)
      at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:78)
      at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:63)
      at hudson.util.RobustReflectionConverter.marshallField(RobustReflectionConverter.java:175)
      at hudson.util.RobustReflectionConverter$2.writeField(RobustReflectionConverter.java:163)
      ... 41 more
      Caused by: java.lang.NullPointerException
      at java.lang.Class.isAssignableFrom(Native Method)
      at hudson.util.XStream2$1.serializedClass(XStream2.java:115)
      at com.thoughtworks.xstream.mapper.MapperWrapper.serializedClass(MapperWrapper.java:34)
      at com.thoughtworks.xstream.mapper.MapperWrapper.serializedClass(MapperWrapper.java:34)
      at com.thoughtworks.xstream.converters.collections.AbstractCollectionConverter.writeItem(AbstractCollectionConverter.java:58)
      at com.thoughtworks.xstream.converters.collections.ArrayConverter.marshal(ArrayConverter.java:45)
      at com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:68)
      at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:78)
      at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:63)
      at com.thoughtworks.xstream.converters.reflection.SerializableConverter$1.defaultWriteObject(SerializableConverter.java:176)
      at com.thoughtworks.xstream.core.util.CustomObjectOutputStream.defaultWriteObject(CustomObjectOutputStream.java:80)
      at java.util.Vector.writeObject(Vector.java:1036)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
      at java.lang.reflect.Method.invoke(Method.java:616)
      at com.thoughtworks.xstream.converters.reflection.SerializationMethodInvoker.callWriteObject(SerializationMethodInvoker.java:100)
      ... 48 more

      Oct 7, 2010 2:35:43 PM hudson.plugins.analysis.core.BuildResult loadResult
      INFO: Loaded data file /home/hudson/jobs/Jobeet/builds/2010-10-07_14-02-19/dry-warnings.xml for build 89

      Oct 7, 2010 2:35:43 PM hudson.plugins.analysis.core.BuildResult loadResult
      INFO: Loaded data file /home/hudson/jobs/Jobeet/builds/2010-10-07_14-02-19/pmd-warnings.xml for build 89

      Oct 7, 2010 2:35:41 PM hudson.plugins.analysis.core.BuildResult loadResult
      INFO: Loaded data file /home/hudson/jobs/Jobeet/builds/2010-10-07_14-02-19/checkstyle-warnings.xml for build 89

      Oct 7, 2010 2:35:39 PM hudson.model.Run run
      INFO: Jobeet #92 main build action completed: SUCCESS

      Oct 7, 2010 2:34:24 PM hudson.TcpSlaveAgentListener
      INFO: JNLP slave agent listener started on TCP port 54637

      Oct 7, 2010 2:34:21 PM hudson.model.Hudson$4 onAttained
      INFO: Completed initialization
      =========================================================================

      Because of this problem hudson is not able to generate "build.xml" file in each build. Instead we could see files like "atomic7696684987998610266.tmp" which looks like incomplete version of "build.xml". The difference has been shown below

      => file "build.xml"

      <stack serialization="custom">
      <unserializable-parents/>
      <vector>
      <default>
      <capacityIncrement>0</capacityIncrement>
      <elementCount>0</elementCount>
      <elementData>
      <null/>
      <null/>
      <null/>
      <null/>
      <null/>
      <null/>
      <null/>
      <null/>
      <null/>
      <null/>
      </elementData>
      </default>
      </vector>
      </stack>

      => file "atomic7696684987998610266.tmp"

      <stack serialization="custom">
      <unserializable-parents/>
      <vector>
      <default>
      <capacityIncrement>0</capacityIncrement>
      <elementCount>0</elementCount>
      <elementData

      I am not sure what exactly is causing this problem, whether hudson itself or JDepend plugin, but this needs to get fixed asap, otherwise JDepend plugin would become useless. I have tested this issue on 2 different projects and found same result.

      Let me know if you need more details.

        Attachments

          Activity

          Hide
          arzala arzala added a comment -

          Is there anyway to recover "build.xml" from "atomicxxxxxxx.tmp" because now all last 15 builds have been unusable?

          Show
          arzala arzala added a comment - Is there anyway to recover "build.xml" from "atomicxxxxxxx.tmp" because now all last 15 builds have been unusable?
          Hide
          lewisham Lewisham added a comment - - edited

          Couple of thoughts without even trying to replicate yet:

          It looks like Hudson core's method of serializing out the JDepend information isn't working anymore. The problem is that it's choking on a java.util.Stack object inside org.codehaus.mojo.jdepend.JDependXMLReportParser.

          The JDepend plugin extends JDependXMLReportParser to avoid duplicated code. I will try doing a cut and paste hack job to see if I can tag the stack object as volatile and stop it being serialized anyway.

          The immediate workaround is just to turn off the JDepend plugin. I believe your builds are just lost. If your builds are so important that you need them recovered, perhaps you should consider doing upgrades to a test box before rolling out to your main server. Hudson updates quickly, and it's strong ecosystem of plugins is a big strength, but it's hard to test all of them.

          I'm reassigning to kohsuke because if Hudson changed but JDepend didn't, something broke in Hudson core that might affect other plugins too. Having incomplete build files is also a bad thing, Hudson's behavior should be to write a build file that lists the failure rather than have an incomplete one that gets cleaned up.

          Show
          lewisham Lewisham added a comment - - edited Couple of thoughts without even trying to replicate yet: It looks like Hudson core's method of serializing out the JDepend information isn't working anymore. The problem is that it's choking on a java.util.Stack object inside org.codehaus.mojo.jdepend.JDependXMLReportParser. The JDepend plugin extends JDependXMLReportParser to avoid duplicated code. I will try doing a cut and paste hack job to see if I can tag the stack object as volatile and stop it being serialized anyway. The immediate workaround is just to turn off the JDepend plugin. I believe your builds are just lost. If your builds are so important that you need them recovered, perhaps you should consider doing upgrades to a test box before rolling out to your main server. Hudson updates quickly, and it's strong ecosystem of plugins is a big strength, but it's hard to test all of them. I'm reassigning to kohsuke because if Hudson changed but JDepend didn't, something broke in Hudson core that might affect other plugins too. Having incomplete build files is also a bad thing, Hudson's behavior should be to write a build file that lists the failure rather than have an incomplete one that gets cleaned up.
          Hide
          arzala arzala added a comment - - edited

          We do use testbox environment before upgrading to main server, but problem seems here that even Hudson didn't notice that build.xml is not available until service was restarted. So for 2 weeks, all graphs and builds were being shown on home page of projects as if like nothing had happened, so we believed that everything is working properly even after upgrade on testbox, so eventually we upgraded to main server.

          This also raises issue that Hudson does keep some build history in memory without need of build.xml file and if coincidently you don't check build history thoroughly (because you are just interested in graphs of home page) you wont realize that actually there is not build history on the disk.

          Moreover I have also noticed following problem around same time http://wiki.jenkins-ci.org/display/JENKINS/Seleniumhq+Plugin?focusedCommentId=46336405&#comment-46336405 Can this also be related to this bug?

          Show
          arzala arzala added a comment - - edited We do use testbox environment before upgrading to main server, but problem seems here that even Hudson didn't notice that build.xml is not available until service was restarted . So for 2 weeks, all graphs and builds were being shown on home page of projects as if like nothing had happened, so we believed that everything is working properly even after upgrade on testbox, so eventually we upgraded to main server. This also raises issue that Hudson does keep some build history in memory without need of build.xml file and if coincidently you don't check build history thoroughly (because you are just interested in graphs of home page) you wont realize that actually there is not build history on the disk. Moreover I have also noticed following problem around same time http://wiki.jenkins-ci.org/display/JENKINS/Seleniumhq+Plugin?focusedCommentId=46336405&#comment-46336405 Can this also be related to this bug?
          Hide
          gasper_k gasper_k added a comment -

          I had exactly the same error, but it seems it's gone with the 1.386 version that was just released. Might be worth trying to upgrade, and re-check.

          Show
          gasper_k gasper_k added a comment - I had exactly the same error, but it seems it's gone with the 1.386 version that was just released. Might be worth trying to upgrade, and re-check.
          Hide
          jrmyl35 jrmyl35 added a comment -

          Same here, problem disappeared with new version. Now using 1.387 on Ubuntu 10.04 x64.

          Show
          jrmyl35 jrmyl35 added a comment - Same here, problem disappeared with new version. Now using 1.387 on Ubuntu 10.04 x64.
          Hide
          arzala arzala added a comment -

          This issue seems gone from 1.386

          Show
          arzala arzala added a comment - This issue seems gone from 1.386

            People

            • Assignee:
              kohsuke Kohsuke Kawaguchi
              Reporter:
              arzala arzala
            • Votes:
              7 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: