• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • core
    • windows jenkins server
      windows client
      chrome browser
      autorefresh is enabled

      leaving the dashboard webpage open (with autorefresh) will accumulate lots of memory. I left it open over the weekend and it was using over 700 MB of ram! you can watch the memory consumption increase ~3-10 MB every time it refreshes (manually or automatically). Sometimes it will decrease to the pre-refreshed amount, but it will always increase over time (instantaneous readings may/may not prove true, but long term averages will).

        1. mem_1.457.jpg
          mem_1.457.jpg
          46 kB
        2. mem_1.460.jpg
          mem_1.460.jpg
          34 kB
        3. OoM.jpg
          OoM.jpg
          8 kB

          [JENKINS-10912] Browser/JS memory leak in dashboard

          In my case auto-refresh is disabled, so I guess it's not related (Jenkins ver. 1.576).

          Stefan Kaltenberger added a comment - In my case auto-refresh is disabled, so I guess it's not related (Jenkins ver. 1.576).

          Danny Staple added a comment -

          I've seen this here too.
          The partial fix with innerHtml (which is the same as this stack overflow thing here: http://stackoverflow.com/a/3785323/490188) perhaps plus Douglas Crockford's purge method might mitigate this.

          My simpler and brute force fix is a GreaseMonkey script:

          if(location.pathname.indexOf('config') == -1) {
            //Reload every hour
            window.setTimeout(function() {location.reload()}, 1000 * 60 * 60)
          }
          

          Which will do for some of our extreme feedback monitors, or accidentally leaving it open overnight in a browser tab.

          Danny Staple added a comment - I've seen this here too. The partial fix with innerHtml (which is the same as this stack overflow thing here: http://stackoverflow.com/a/3785323/490188 ) perhaps plus Douglas Crockford's purge method might mitigate this. My simpler and brute force fix is a GreaseMonkey script: if (location.pathname.indexOf( 'config' ) == -1) { //Reload every hour window.setTimeout(function() {location.reload()}, 1000 * 60 * 60) } Which will do for some of our extreme feedback monitors, or accidentally leaving it open overnight in a browser tab.

          Laurențiu Păncescu added a comment - - edited

          I see a significant memory leak on ci.centos.org - it doesn't affect just the Dashboard. The memory usage for that tab increases to 1.7GB in Chrome and 1GB in Safari, over less than 3 hours (I also see this with Firefox on both OS X and Linux, although the memory increase seems less steep). I posted details on the centos-devel mailing list.

          The Chrome Developer Tools point to refreshPart from hudson-behavior.js as the culprit. Indeed, using 'delete node' from the Inspector to remove the #buildQueue and #executors divs stops the memory leak. I created a self-contained test to illustrate the problem, using just plain Javascript, without any external libraries: https://github.com/lpancescu/xhr-memory-leak.

          The least intrusive fix for Jenkins would be to remove the call to refreshPart from function f, and use setInterval instead of setTimeout (this is what noleak.html from my test repo does). The more elegant solution would be to use Ajax.PeriodicalUpdater from Prototype.js, which is designed for this use case. If you tell me which variant you prefer, I can send you a pull request on GitHub.

          Laurențiu Păncescu added a comment - - edited I see a significant memory leak on ci.centos.org - it doesn't affect just the Dashboard. The memory usage for that tab increases to 1.7GB in Chrome and 1GB in Safari, over less than 3 hours (I also see this with Firefox on both OS X and Linux, although the memory increase seems less steep). I posted details on the centos-devel mailing list . The Chrome Developer Tools point to refreshPart from hudson-behavior.js as the culprit. Indeed, using 'delete node' from the Inspector to remove the #buildQueue and #executors divs stops the memory leak. I created a self-contained test to illustrate the problem, using just plain Javascript, without any external libraries: https://github.com/lpancescu/xhr-memory-leak . The least intrusive fix for Jenkins would be to remove the call to refreshPart from function f, and use setInterval instead of setTimeout (this is what noleak.html from my test repo does). The more elegant solution would be to use Ajax.PeriodicalUpdater from Prototype.js, which is designed for this use case. If you tell me which variant you prefer, I can send you a pull request on GitHub.

          Daniel Beck added a comment -

          lpancescu Depending on how extensive the change for PeriodicUpdater is, it'll probably be easier to get the apparently minimal fix of setInterval integrated. If it's easy enough to do so enough, you could also open two PRs and indicate they are alternative solutions.

          Daniel Beck added a comment - lpancescu Depending on how extensive the change for PeriodicUpdater is, it'll probably be easier to get the apparently minimal fix of setInterval integrated. If it's easy enough to do so enough, you could also open two PRs and indicate they are alternative solutions.

          I implemented the 'elegant' way in my test repo (noleak-prototype.html) and tested for 6 hours. It doesn't leak memory, but I can't use it in a Jenkins context, since the server response includes the divs whose content should be replaced, and I'd still need to rebind the behaviors to the received DOM tree anyway.

          The 'minimal' fix is better in this case - please see pull request #2539.

          Laurențiu Păncescu added a comment - I implemented the 'elegant' way in my test repo (noleak-prototype.html) and tested for 6 hours. It doesn't leak memory, but I can't use it in a Jenkins context, since the server response includes the divs whose content should be replaced, and I'd still need to rebind the behaviors to the received DOM tree anyway. The 'minimal' fix is better in this case - please see pull request #2539 .

          Code changed in jenkins
          User: lpancescu
          Path:
          war/src/main/webapp/scripts/hudson-behavior.js
          http://jenkins-ci.org/commit/jenkins/096614a6d72c19633909248cb5b06a179b8b4040
          Log:
          JENKINS-10912 Use setInterval in refreshPart (#2539)

          The current implementation of refreshPart creates a new closure every 5
          seconds, which, in combination with XMLHttpRequest objects, results in a
          significant memory leak in all major browsers. By using
          window.setInterval to schedule periodic refreshes, only one closure per
          id is created. Please see issue #10912 in the Jenkins tracker for
          further details.

          • Stop periodical calls if we can't find the div
          • Don't check if isRunAsTest changed after page load

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: lpancescu Path: war/src/main/webapp/scripts/hudson-behavior.js http://jenkins-ci.org/commit/jenkins/096614a6d72c19633909248cb5b06a179b8b4040 Log: JENKINS-10912 Use setInterval in refreshPart (#2539) JENKINS-10912 Use setInterval in refreshPart The current implementation of refreshPart creates a new closure every 5 seconds, which, in combination with XMLHttpRequest objects, results in a significant memory leak in all major browsers. By using window.setInterval to schedule periodic refreshes, only one closure per id is created. Please see issue #10912 in the Jenkins tracker for further details. Stop periodical calls if we can't find the div Don't check if isRunAsTest changed after page load

          Daniel Beck added a comment -

          Fixed in 2.23

          Daniel Beck added a comment - Fixed in 2.23

          Dilip Mahadevappa added a comment - - edited

          Which version of LTS core this fix is merged into? We are having same issue with 1.642.3 LTS

          Dilip Mahadevappa added a comment - - edited Which version of LTS core this fix is merged into? We are having same issue with 1.642.3 LTS

          Daniel Beck added a comment -

          Labels: 2.19.4-fixed

          It's not rocket science

          Daniel Beck added a comment - Labels: 2.19.4-fixed It's not rocket science

          Code changed in jenkins
          User: lpancescu
          Path:
          war/src/main/webapp/scripts/hudson-behavior.js
          http://jenkins-ci.org/commit/jenkins/2f0632ae189a11b439e10a59918434f3248a5787
          Log:
          JENKINS-10912 Use setInterval in refreshPart (#2539)

          The current implementation of refreshPart creates a new closure every 5
          seconds, which, in combination with XMLHttpRequest objects, results in a
          significant memory leak in all major browsers. By using
          window.setInterval to schedule periodic refreshes, only one closure per
          id is created. Please see issue #10912 in the Jenkins tracker for
          further details.

          • Stop periodical calls if we can't find the div
          • Don't check if isRunAsTest changed after page load

          (cherry picked from commit 096614a6d72c19633909248cb5b06a179b8b4040)

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: lpancescu Path: war/src/main/webapp/scripts/hudson-behavior.js http://jenkins-ci.org/commit/jenkins/2f0632ae189a11b439e10a59918434f3248a5787 Log: JENKINS-10912 Use setInterval in refreshPart (#2539) JENKINS-10912 Use setInterval in refreshPart The current implementation of refreshPart creates a new closure every 5 seconds, which, in combination with XMLHttpRequest objects, results in a significant memory leak in all major browsers. By using window.setInterval to schedule periodic refreshes, only one closure per id is created. Please see issue #10912 in the Jenkins tracker for further details. Stop periodical calls if we can't find the div Don't check if isRunAsTest changed after page load (cherry picked from commit 096614a6d72c19633909248cb5b06a179b8b4040)

            Unassigned Unassigned
            abadird david abadir
            Votes:
            20 Vote for this issue
            Watchers:
            24 Start watching this issue

              Created:
              Updated:
              Resolved: