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

Computer.threadPoolForRemoting can be poisoned by bad code

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Minor Minor
    • core
    • 2.449, 2.440.3

      Whilst tracking down a bug in a prviate plugin it was discovered that the bug was caused by the threads contextClassLoader being set to hudson.PluginManager$UberClassLoader.
      In cases where the bug did not appear the contextClassloader was the WebAppClassLoader.

      This was surprising as the code in question did not set the context classloader and was running on the Computer.threadPoolForRemoting ThreadPool.

      This shows that the contextClassloader in a task submitted to this ThreadPool is not stable.

      It is expected that the state of a thread run in an executor from Jenkins core is in a deterministic state. 

      The threadpool should be tolerant of when ad by whom Threads are created as well as ensure state is clean/stable before running tasks.
      e..g - in a way similar to the Timer threads by using like the ContextResettingExecutorService

          [JENKINS-72796] Computer.threadPoolForRemoting can be poisoned by bad code

          James Nord added a comment -

          the code is a ContextResettingExecutorService so 😕😕

          James Nord added a comment - the code is a ContextResettingExecutorService so 😕😕

          Jesse Glick added a comment -

          I suspect that it is ClassLoaderSanityThreadFactory which is missing from threadPoolForRemoting.

          Jesse Glick added a comment - I suspect that it is ClassLoaderSanityThreadFactory which is missing from threadPoolForRemoting .

            teilo James Nord
            teilo James Nord
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: