| I've been trying to track this down, but have run out of time. It definitely seems to be the issue mentioned above that the contextClassLoader is set to null, but where this is getting set to null I don't know. I've traced this back up the stack and all the threads that it's operating on are spawned by the pipeline plugins (when a thread spawns another thread, the contextClassLoader is inherited from the parent). I could see that the threads in the pipeline plugins had the contextClassLoader set to `null` sometimes, but I couldn't track down where in its myriads of threads and threadpools the root of the issue where it was setting the contextClassLoader to null that triggered this issue (there are lots of instances where it does set it to null, but a lot of those are 'valid' given the context. Unfortunately, I can only see this issue on our build infrastructure which is hard to debug (attaching a debugger will basically lock up the Jenkins instance) as there is so much going on. Mykola Ulianytskyi - are you able to recreate the issues in a fresh/newly installed instance that I could run locally to get a better handle on what's going on? Remote debugging isn't working for me. What I was attempting to do was to launch Jenkins with debug flags and attach a debugger to Thread.setContextClassLoader and get the debugger to break if it is setting it no null. As I said, this happened so much it was hard to identify where this was doing it 'wrongly'. Maybe Mykola Ulianytskyi could have some luck tracing it down? Some possibly useful stack traces I got are attached if they are useful to anyone. I got lots where it was in the sun.net.www.http package, but these seem valid given the comments here and given the fact that that thread is not re-used. |
