After discovering this problem while we were migrating our configuration to a new Jenkins master, this seems to be a race condition on Reloading the Configuration while a new job is queued. I was able to reproduce this reliably through the following steps (msinclair's notes from 26582 aided in this):
- Start a fresh server (slave nodes aren't necessary to setup)
- Add a Freestyle Project
- This job will need to run for at least a few seconds, I setup a Unix shell script to just "sleep 90"
- Build revision 1 of the new project
- Run the following bash script that will continually reload the configuration in the background:
while [ true ]; do
curl -X POST http://localhost:8080/reload
sleep 1
done
- Attempt to queue additional builds from the same project, this can be spam-clicked for a few seconds
- Observe that the project itself will not display the queued jobs
- Go to the main Jenkins page and observe that the Queue will have multiple jobs for the same project queued
- Cancel or let the initial job fail, the next job in the queue will attempt to use the same build revision number as cause the above crash.
I was attempting to track down when the issue actually starting showing up and the strange build queue issue seems to go back at least before April of 2014. The crash seems to have occurred due to a change between November 11, 2014 and January 9th, 2015 (these were the arbitrary commits I manually checked out). I think the crash is related, but is actually caused by these weird queue issues while reloading.
Note: Although the reproduce steps here are for simplicity I think this is observed in production conditions when a reload occurs and a non-manual build trigger happens - either by a periodic build, SCM trigger, or other means.
Linked duplicate issues since I was also running into this problem. It seems 26582 was closed as fixing a slightly separate problem, but the original submission still seems to be the same.