• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • other
    • None
    • AIX 5.3.9, JDK 5

      I don't have any value in the combo above for versions, so I'll give the information here:
      the problem appeared between 1.389 (ok) and 1.390 (ko).

      With 1.390, the only log I can see seems to come from plugins.
      The problem is present with either maven 2 native builds and freestyle jobs (though the result seems a bit different).
      The build seems to behave quite normally, since it stays green when it was before, and so on.

      With M2 native builds, it seems like the build is triggered in background with the typical line:

      <===[HUDSON REMOTING CAPACITY]===>Executing Maven: -B -f /ic/.hudson/jobs/corp-shared-resources/workspace/corp-shared-resources/pom.xml -e -Dsurefire.useFile=false -U clean deploy

      And then, without any additional line between, the logs corresponding to surefire report gathering for the hudson plugin is shown:

      [HUDSON] Enregistrement des résultats des tests
      [HUDSON] Archiving /ic/.hudson/jobs/corp-shared-resources/workspace/corp-shared-resources/pom.xml to /ic/.hudson/jobs/corp-shared-resources/modules/fr.corp$corp-shared-resources/builds

      With freestyle jobs, it only shows the execution of external .sh:

      [workspace] $ /bin/sh -xe /ic/tmp/hudson64022.sh
      [workspace] $ /bin/sh -xe /ic/tmp/hudson64023.sh

      The difference is that in this case, the build fails w/ 1.390 and successes w/ 1.389.

      Sorry for being so vague.
      If you need more information, please let me know.
      If I find time, I'll try to have a look at the commit differences between 389 and 390.

      PS : I have quite a lot of plugins activated, so I guess it could also be related to that.
      PS2: Sorry, I had a hard time choosing the right component. I'm quite sure I didn't .
      Cheers

          [JENKINS-8420] No more build logs

          For the record, I just tried with 1.395 and same problem back.

          Baptiste Mathus added a comment - For the record, I just tried with 1.395 and same problem back.

          For the record, just finished bisecting:
          $ git bisect good
          d1543575e2b4bcb0938a2bc88df589c462b227ef is the first bad commit
          commit d1543575e2b4bcb0938a2bc88df589c462b227ef
          Author: Kohsuke Kawaguchi <kk@kohsuke.org>
          Date: Fri Dec 10 23:50:17 2010 -0800

          [FIXED HUDSON-8244] turns out Process.getErrorStream() needs to be explicitly closed even when stderr is redirected to stdout.

          :100644 100644 083f97cf5662d25779c725611a88d510e185a0c8 5482f2169f5fce3dd140dc33253a7abda092e157 M changelog.html
          :040000 040000 4710f87852584c6c7705e336031972845b664405 a9feead33bec2ab58c331def0c1296c6607117a6 M core

          => https://github.com/jenkinsci/jenkins/commit/d1543575e2b4bcb0938a2bc88df589c462b227ef

          Now, I'm gonna have a look at the diff to see if I can see anything (obvious, hopefully).

          Cheers

          Baptiste Mathus added a comment - For the record, just finished bisecting: $ git bisect good d1543575e2b4bcb0938a2bc88df589c462b227ef is the first bad commit commit d1543575e2b4bcb0938a2bc88df589c462b227ef Author: Kohsuke Kawaguchi <kk@kohsuke.org> Date: Fri Dec 10 23:50:17 2010 -0800 [FIXED HUDSON-8244] turns out Process.getErrorStream() needs to be explicitly closed even when stderr is redirected to stdout. :100644 100644 083f97cf5662d25779c725611a88d510e185a0c8 5482f2169f5fce3dd140dc33253a7abda092e157 M changelog.html :040000 040000 4710f87852584c6c7705e336031972845b664405 a9feead33bec2ab58c331def0c1296c6607117a6 M core => https://github.com/jenkinsci/jenkins/commit/d1543575e2b4bcb0938a2bc88df589c462b227ef Now, I'm gonna have a look at the diff to see if I can see anything (obvious, hopefully). Cheers

          mbaker000 added a comment -

          Maybe the symptom of this FindBugs message relating to OpenJDK?

          Changes to logger could be lost in hudson.WebAppMain.installLogger()
          
          OpenJDK introduces a potential incompatibility. In particular, the java.util.logging.Logger behavior has changed. Instead of using strong references, it now uses weak references internally. That's a reasonable change, but unfortunately some code relies on the old behavior - when changing logger configuration, it simply drops the logger reference. That means that the garbage collector is free to reclaim that memory, which means that the logger configuration is lost. For example, consider:
          
          public static void initLogging() throws Exception {
           Logger logger = Logger.getLogger("edu.umd.cs");
           logger.addHandler(new FileHandler()); // call to change logger configuration
           logger.setUseParentHandlers(false); // another call to change logger configuration
          }
          The logger reference is lost at the end of the method (it doesn't escape the method), so if you have a garbage collection cycle just after the call to initLogging, the logger configuration is lost (because Logger only keeps weak references).
          
          public static void main(String[] args) throws Exception {
           initLogging(); // adds a file handler to the logger
           System.gc(); // logger configuration lost
           Logger.getLogger("edu.umd.cs").info("Some message"); // this isn't logged to the file as expected
          }
          Ulf Ochsenfahrt and Eric Fellheimer

          This was just an occurrence in this one file, but I'm sure it happens elsewhere.

          mbaker000 added a comment - Maybe the symptom of this FindBugs message relating to OpenJDK? Changes to logger could be lost in hudson.WebAppMain.installLogger() OpenJDK introduces a potential incompatibility. In particular, the java.util.logging.Logger behavior has changed. Instead of using strong references, it now uses weak references internally. That's a reasonable change, but unfortunately some code relies on the old behavior - when changing logger configuration, it simply drops the logger reference. That means that the garbage collector is free to reclaim that memory, which means that the logger configuration is lost. For example, consider: public static void initLogging() throws Exception { Logger logger = Logger.getLogger("edu.umd.cs"); logger.addHandler(new FileHandler()); // call to change logger configuration logger.setUseParentHandlers(false); // another call to change logger configuration } The logger reference is lost at the end of the method (it doesn't escape the method), so if you have a garbage collection cycle just after the call to initLogging, the logger configuration is lost (because Logger only keeps weak references). public static void main(String[] args) throws Exception { initLogging(); // adds a file handler to the logger System.gc(); // logger configuration lost Logger.getLogger("edu.umd.cs").info("Some message"); // this isn't logged to the file as expected } Ulf Ochsenfahrt and Eric Fellheimer This was just an occurrence in this one file, but I'm sure it happens elsewhere.

          Baptiste Mathus added a comment - - edited

          @mbaker000 Well, apart from the fact I'm note sure I see the link between the logging system (say JUL, SLF4J or so) and the Jenkins build logs, my CI server isn't running on OpenJDK, but IBM one.

          Cheers

          Baptiste Mathus added a comment - - edited @mbaker000 Well, apart from the fact I'm note sure I see the link between the logging system (say JUL, SLF4J or so) and the Jenkins build logs, my CI server isn't running on OpenJDK, but IBM one. Cheers

          mbaker000 added a comment -

          @batmat, Are you talking about the output collected from stdout while a build is executing, or the backend system logs?

          mbaker000 added a comment - @batmat, Are you talking about the output collected from stdout while a build is executing, or the backend system logs?

          As stated in the title, I mean "build logs", so yes, the ones collected from stdout/stderr during the build.

          Baptiste Mathus added a comment - As stated in the title, I mean "build logs", so yes, the ones collected from stdout/stderr during the build.

          For the record, new version of the patch reworked after comments from Brian Atkinson: https://github.com/jenkinsci/jenkins/pull/37.

          Cheers

          Baptiste Mathus added a comment - For the record, new version of the patch reworked after comments from Brian Atkinson: https://github.com/jenkinsci/jenkins/pull/37 . Cheers

          Code changed in jenkins
          User: Kohsuke Kawaguchi
          Path:
          changelog.html
          core/src/main/java/hudson/Proc.java
          http://jenkins-ci.org/commit/core/8b41031750465f710bef219114b885134faf68ea
          Log:
          [FIXED JENKINS-8420] recording 3c5c2c5cc335c1bb19c4e92bd4f75a715468dd33

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: changelog.html core/src/main/java/hudson/Proc.java http://jenkins-ci.org/commit/core/8b41031750465f710bef219114b885134faf68ea Log: [FIXED JENKINS-8420] recording 3c5c2c5cc335c1bb19c4e92bd4f75a715468dd33

          dogfood added a comment -

          Integrated in jenkins_main_trunk #512
          [FIXED JENKINS-8420] recording 3c5c2c5cc335c1bb19c4e92bd4f75a715468dd33

          Kohsuke Kawaguchi :
          Files :

          • changelog.html
          • core/src/main/java/hudson/Proc.java

          dogfood added a comment - Integrated in jenkins_main_trunk #512 [FIXED JENKINS-8420] recording 3c5c2c5cc335c1bb19c4e92bd4f75a715468dd33 Kohsuke Kawaguchi : Files : changelog.html core/src/main/java/hudson/Proc.java

          FTR : fix version => 1.399 (to be released soon).

          Baptiste Mathus added a comment - FTR : fix version => 1.399 (to be released soon).

            Unassigned Unassigned
            batmat Baptiste Mathus
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: