-
Bug
-
Resolution: Fixed
-
Minor
-
-
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
- links to
[JENKINS-72796] Computer.threadPoolForRemoting can be poisoned by bad code
Assignee | New: James Nord [ teilo ] |
Status | Original: Open [ 1 ] | New: In Progress [ 3 ] |
Description |
Original:
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 someone has changed the contextClassloader in a task submitted to this threadpool but did not clean up. Whilst this is a bug somewhere that needs to be fixed, the threadpool should be tolerant of this by ensuring the threads are in a deterministic state before running tasks. e..g - in a way similar to the `Timer` threads by using like the [ContextResettingExecutorService|https://github.com/jenkinsci/jenkins/blob/19f0140adef29e86d150faa056a22ceb011c8b03/core/src/main/java/jenkins/util/ContextResettingExecutorService.java] |
New:
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 someone has changed the {{contextClassloader }}in a task submitted to this {{ThreadPool}} but did not clean up. Whilst this is a bug somewhere that needs to be fixed, the threadpool should be tolerant of this by ensuring the threads are in a deterministic state before running tasks. e..g - in a way similar to the `Timer` threads by using like the [ContextResettingExecutorService|https://github.com/jenkinsci/jenkins/blob/19f0140adef29e86d150faa056a22ceb011c8b03/core/src/main/java/jenkins/util/ContextResettingExecutorService.java] |
Description |
Original:
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 someone has changed the {{contextClassloader }}in a task submitted to this {{ThreadPool}} but did not clean up. Whilst this is a bug somewhere that needs to be fixed, the threadpool should be tolerant of this by ensuring the threads are in a deterministic state before running tasks. e..g - in a way similar to the `Timer` threads by using like the [ContextResettingExecutorService|https://github.com/jenkinsci/jenkins/blob/19f0140adef29e86d150faa056a22ceb011c8b03/core/src/main/java/jenkins/util/ContextResettingExecutorService.java] |
New:
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 someone has changed the {{contextClassloader }}in a task submitted to this {{ThreadPool}} but did not clean up. Whilst this is a bug somewhere that needs to be fixed, the threadpool should be tolerant of this by ensuring the threads are in a deterministic state before running tasks. e..g - in a way similar to the {{Timer}} threads by using like the [ContextResettingExecutorService|https://github.com/jenkinsci/jenkins/blob/19f0140adef29e86d150faa056a22ceb011c8b03/core/src/main/java/jenkins/util/ContextResettingExecutorService.java] |
Description |
Original:
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 someone has changed the {{contextClassloader }}in a task submitted to this {{ThreadPool}} but did not clean up. Whilst this is a bug somewhere that needs to be fixed, the threadpool should be tolerant of this by ensuring the threads are in a deterministic state before running tasks. e..g - in a way similar to the {{Timer}} threads by using like the [ContextResettingExecutorService|https://github.com/jenkinsci/jenkins/blob/19f0140adef29e86d150faa056a22ceb011c8b03/core/src/main/java/jenkins/util/ContextResettingExecutorService.java] |
New:
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 someone has changed the {{contextClassloader}} in a task submitted to this {{ThreadPool}} but did not clean up. Whilst this is a bug somewhere that needs to be fixed, the threadpool should be tolerant of this by ensuring the threads are in a deterministic state before running tasks. e..g - in a way similar to the {{Timer}} threads by using like the [ContextResettingExecutorService|https://github.com/jenkinsci/jenkins/blob/19f0140adef29e86d150faa056a22ceb011c8b03/core/src/main/java/jenkins/util/ContextResettingExecutorService.java] |
Resolution | New: Cannot Reproduce [ 5 ] | |
Status | Original: In Progress [ 3 ] | New: Closed [ 6 ] |
Resolution | Original: Cannot Reproduce [ 5 ] | |
Status | Original: Closed [ 6 ] | New: Reopened [ 4 ] |
the code is a ContextResettingExecutorService so 😕😕