We also got this error when we upgraded from Hudson 1.372 to Jenkins 1.403 on a Ubuntu box. We had several Hudson servers that we upgraded, and only one had this issue.

Got this error when upgrading from 1.398 to 1.403

I think this is just a Jenkins 1.403 bug.

I upgraded from 1.398 to 1.403 and have this problem.

For anyone who is experiencing this problem, I have found a temporary workaround. First create a new job with the new Jenkins, then add a build step in the new job. After that, you should be able to add build steps to any existing jobs that wouldn't have worked before.

Using Chrome's developer tool or Firefox's Firebug extension, we get this error when adding a build step:
POST http://<HOST>/$stapler/bound/43328235-2ba7-416b-bda7-66b3834cc54c/render 404 (Not Found)

I had the same problem with the Jenkins ver. 1.408
but it occurred as not Jenkins but browser issue - it did not work in Firefox 3.6.15, but it works as normal in Opera 11.10, in Firefox 4.0, and in Chrome 10.0.648.205

I was having this issue on Ubuntu 10.10 and Jenkins 1.413. The problem was that "Prevent Cross Site Request Forgery exploits" was checked. After deactivating that, I no longer had the issue.

For ours, the "Prevent Cross Site Request Forgery exploits" was never checked.

I see the problem on Jenkins 1.421
"Prevent Cross Site Request Forgery Exploits" was never checked. The malfunctioniing "Add Buidl Step" button occurs on both IE 8.07600 and Firefox 3.6.18. The work around of creating a new job and adding a build step did not work for me as the "Add build step" remains broken in the new job.

Since this bug effectively disbales new developement and test functions, I bumped the priority to "blocker" as defined in Bug tracker bug entry screen.

Just another data point...

I upgrade my laptop test system running Win7 to 1.421 and I do not see the broken "Add Build Step: behavior

Our production system is 1.421 on Red hat where I do see the broken "Add Build Step" behavior.

And another data point...

This issue is broader than just hudson to jenkins upgrades. I never installed/nor upgraded from hudson.

Changed bug description to reflect that this issue is broader than just the (frequent) cases of hudson to jenkins upgrades.

Also seeing this on a fresh installation on Ubuntu 11.04 with Chrome 13 on Mac.

I switched it to Firefox 3.6 on Mac, the problem is gone... Would really like to see this to be fixed.

I hate this bug. I haven't been able to zone in on an exact, repeatable, set of steps, but if you configure the job,( i.e click a few things, save and return to the job), the button sometimes, temporarily works again.

One you find that black magic to get the button temporarily working again, add tons of steps (cuz you can always delete them), and now you can simply use that saved job as a template for all your multi build step jobs.

I hate this bug.

I suspect this is being caused by a badly behaved plugin (otherwise many more people would have reported it).

Can you please download a fresh Jenkins, try it out, and then keep adding the plugins that you have installed in your problem installation, one by one, to identify which plugin is breaking the button?

Hey there, I was working on another issue here in Jenkins JIRA and decided try some other issues while my code was compiling and testing.

Unfortunately I couldn't reproduce this issue . Here's what I did:

• Downloaded Hudson 1.398 and Jenkins 1.403
• Exported HUDSON_HOME to some directory in my personal folder
• Started Hudson 1.398 with java -jar ...
• Checked the "Prevent Cross Site Request Forgery exploits" check box
• Created a new Free Style build
• Added a Shell build step to print to console some random message
• Stopped Hudson and started Jenkins 1.403 using the same workspace
• Verified that "Prevent Cross Site Request Forgery exploits" was still marked and that the update center was pointing to jenkins instead of hudson
• Executed the job without problems
• Added a new build step to print another message, ok
• Installed MSBuild plug-in
• Added as build step to execute MSBuild. The configuration was saved and I could remove this build step later and the job configuration was still ok

Here are my System Properties: http://pastebin.com/LTB0hL0B

And some extra information:
Firefox 5.0
Chrome 13.0.782.107
Ubuntu 11.04

Sorry if I couldn't be of more help here. Perhaps if the users who are able to reproduce this issue posted more information about their environments somebody could isolate the problem.

Cheers, good night!
Bruno

We also got this error

• on firefox 6.0.1, it's ok: *
  POST http://HOST:8080/$stapler/bound/eb0bd019-f203-4471-93b1-a972c8c8a82e/render [HTTP/1.1 200 OK 94ms]

• on Chrome 5.0.396.0, it's NOT OK : *
  Request URL:http://HOST:8080/$stapler/bound/9dab85e8-9b1c-46d8-9ad5-c8ea59c690ed/render Status Code:404 Not Found

• on Chrome 14.0.835.126 beta-m, it's NOT OK *
  http://HOST:8080/$stapler/bound/cf4bf2ca-1cad-4a90-a68f-c144d5dbc104/render 404 (Not Found) render

• Server's ENV *
  Jenkins (1.428) standalone /Jenkins (1.423) standalone
  hudson.lifecycle hudson.lifecycle.WindowsServiceLifecycle
  java.runtime.version 1.6.0_26-b03
  java.version 1.6.0_26
  java.vm.version 20.1-b02
  os.arch x86
  os.name Windows XP
  os.version 5.1
  sun.os.patch.level Service Pack 3

This will happen when more than 22 elements(>22, >=23) added to conf_spec, with using of clearcase plugin.

This will happen when more than 22 elements(>22, >=23) added to conf_spec, with using of clearcase plugin.

I've experienced the same problem independently of the "Prevent Cross Site Request Forgery exploits" settings.

It works now. In my settings the bug was in an intermediate HTTP proxy. It was encoding the URL path: replacing the '$' of '/$stapler' by '%24'.

Shouldn't Jenkins handle that encoding ?

• Client: Firefox 11 or Chromium 17.
• Server: Debian testing.

Doesn't look like a clearcase plugin issue since it seems to happen with a random set of plugins.

Experienced this problem too on Jenkins ver. 1.462, on Ubuntu 12.04.

Turning off Prevent Cross Site Request Forgery exploits resolved the issue for me.

The URL in question "$stapler/bound/GUID/" is used for lazy rendering of fragments. These IDs are session local, transient during a life of an instance. So it is unlikely that how $JENKINS_HOME came into being (whether it was an upgrade or a fresh install) is related to the bug.

I noticed that those transient objects are held via WeakReference. I wonder if people seeing those issues are under strong memory pressure, and those weak references are getting released before they are actually used?

Could someone check my hypothesis by bumping up the heap size? I'll add some logging so that we can verify this.

In 1.467 I put the probe code that provides optional logging.

To enable this optional logging, first execute the following code in Groovy console. This enables this debug logging feature:

org.kohsuke.stapler.bind.BoundObjectTable.DEBUG_LOGGING=true;

Then, from type http://localhost:8080/$stapler/bound/table/enableLogging in the address bar. If this page reports back that the logging is enabled, your HTTP session and object binding activity is now logged to the server console.

You can then visit the configuration page, etc.

When you notice that that "add build step" (or some other similar activities that loads additional HTTP fragments) aren't working, check the developer tool to look up the GUID of the bound object that's causing the issue. Then search that GUID in the server log to see if BoundObjectTable reports anything about that GUID.

Thank you for your cooperation in the data gathering process. Your input would help us understand the root cause better.

Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
core/pom.xml
http://jenkins-ci.org/commit/jenkins/0f03a70c9c939db14adfd7a3ad29cd08fa566e07
Log:
JENKINS-9142 added probe.

Integrated a new version of Stapler that provides debug logging for the
problem. See the ticket for more details of how to enable this probe.

Integrated in jenkins_ui-changes_branch #30
JENKINS-9142 added probe. (Revision 0f03a70c9c939db14adfd7a3ad29cd08fa566e07)

Result = SUCCESS
Kohsuke Kawaguchi : 0f03a70c9c939db14adfd7a3ad29cd08fa566e07
Files :

• core/pom.xml

I'm afraid I'm having this issue and having trouble following your instructions for diagnosis, Kohsuke. I was able to download and install the newest WAR (1.470), download the CLI and run groovysh, successfully set the debug property to true, hit that enableLogging URL successfully, but now I'm confused as to where I should be seeing the logging.

I would love to help data-gathering to resolve this issue (as its a blocker for me at the moment), could someone direct me towards where I can see the logs?

Thanks very much!

WillBuck and I were able to find the console, Here is what we saw in our logs:

18-Jun-2012 16:56:52.913 FINE org.acegisecurity.context.HttpSessionContextIntegrationFilter.readSecurityContextFromSession No HttpSession currently exists
18-Jun-2012 16:56:52.913 FINE org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter New SecurityContext instance will be associated with SecurityContextHolder
18-Jun-2012 16:56:52.913 FINE org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter Authorization header: null
18-Jun-2012 16:56:52.914 FINE org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter Populated SecurityContextHolder with anonymous token: 'org.acegisecurity.providers.anonymous.AnonymousAuthenticationToken@831469b3: Username: anonymous; Password: [PROTECTED]; Authenticated: true; Details: org.acegisecurity.ui.WebAuthenticationDetails@ffffe21a: RemoteIpAddress: 10.10.10.10; SessionId: null; Granted Authorities: '
18-Jun-2012 16:56:52.914 FINE org.kohsuke.stapler.Stapler.service Processing request for /$stapler/bound/d621eece-00aa-489d-81d1-232f1cdd4b0d/render
18-Jun-2012 16:56:52.914 FINE org.kohsuke.stapler.Dispatcher.trace -> evaluate(<org.kohsuke.stapler.bind.BoundObjectTable@4ab118d8> :org.kohsuke.stapler.bind.BoundObjectTable,"/d621eece-00aa-489d-81d1-232f1cdd4b0d/render")
18-Jun-2012 16:56:52.914 FINE org.kohsuke.stapler.Dispatcher.trace -> evaluate(((StaplerFallback)<org.kohsuke.stapler.bind.BoundObjectTable@4ab118d8>).getStaplerFallback(),"/d621eece-00aa-489d-81d1-232f1cdd4b0d/render")
18-Jun-2012 16:56:52.915 FINE org.acegisecurity.context.HttpSessionContextIntegrationFilter.storeSecurityContextInSession The HttpSession is currently null, and the HttpSessionContextIntegrationFilter is prohibited from creating an HttpSession (because the allowSessionCreation property is false) - SecurityContext thus not stored for next request
18-Jun-2012 16:56:52.915 FINE org.acegisecurity.ui.ExceptionTranslationFilter.doFilter Chain processed normally
18-Jun-2012 16:56:52.915 FINE org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter SecurityContextHolder now cleared, as request processing completed

Also, logging in seems to make the issue go away for 1.470 and 1.456

Does seem to be some kind of securities issue in our case; Crowd and LDAP plugins installed, currently set to authenticate to Active Directory, logging in seems to make the issue go away. We have things set to 'Anyone can do anything', but in the case of these AJAX requests, perhaps 'anything' isn't quite that global?

I am using Jenkins own DB for security, with project-specific matrix permissions. During job configuration (for new or existing jobs), the add build step failed for all options, using OSX/Chrome19.0.1084.56 and OSX/Firefox12.0 (about 270 yui "expected declaration but found '*'" per page loads appeared in the FF error logs). I disabled the "Prevent Cross Site Request Forgery exploits" property in the Jenkins configuration (I had the crumb algo enabled as well), and the add build step started working again.

I have just got the same bug in 1.475? It appeared after I add more projects, thats it?

On Ubuntu 11.10 (GNU/Linux 3.0.0-14-server x86_64)

FIXED: for me, it was a cookie issue. I verified this also by de/re-activating cookies. And I cleaned cache in between activating and deactivating cookies.

Ran into this issue with both Jenkins 1.482 and 1.483. It only happened with one URL (a second test server I ran did not experience the same issue, but it was run on a different box).

At Daniel Latter's advice from the previous comment, clearing the cache seemed to solve the issue.

We run into this issue with Jenkins 1.493 so we are unable to add build steps at the moment!

Tested with Chrome 23, FF 16.01 and IE 8.

Any ideas?

Any news on this topic? We're still unable to configure jobs with additional build steps! :-|

This problem is affecting me in Jenkins 1.464. I managed to work around it by using a chrome incognito window, so it probably does have to do with cookies.

Anyone affected should look in their browser’s JavaScript console for errors, as well as enabling bound object logging as Kohsuke described earlier.

I got the same problem when trying to add portlets to the dashboard view in 1.501. Prepared to agree with Edward Griffin that it relates to the cookies. I had a lot of JSESSIONID.xxxxxxxx cookies, removing all of them seemed to solve the problem (so I guess it might have choosen the wrong one). Other than the broken link (404) I could not find any other errors.

Similar problem here: choosing items from "Add axis" in a matrix job didn't work; the JS console showed a 404 for all three available axis types.

Running in an incognito browser window, it worked fine (we don't use any authentication in Jenkins at the moment).

As with Christer Moren above, I had maybe 90 JSESSIONID cookies in my regular browser window for the Jenkins domain. Restarting the browser didn't fix things, but clearing all cookies for the domain did...

For what it's worth, I did enable bound object logging, but no output was ever shown.

Only when I opened the incognito browser window, where the problem didn't exist, did I start to see bound object logs appearing. The logs themselves in this case were unremarkable.

I was able to resolve this issue by resolving a context path docBase misconfiguration in my tomcat configuration (server.xml).

Reserve Fixed for acknowledged bugs with a specific delivered fix.

I'm still able to reproduce this issue. Adding post build steps is not possible. However this problem only occurs when accessing Jenkins over a proxy. Direct access to the same instance is working fine.

• Jenkins ver. 1.554.2
• Jenkins is started "standalone" - not within a Tomcat. (java -jar jenkins.war)

Jenkins access_log:

[ci@myhost jenkins]$ less access_log | grep "$stapler/bound"

172.17.2.152 - - [13/Aug/2014:08:47:17 +0200] "POST /ci/$stapler/bound/14d7256f-189c-4f7d-bc25-badacbc9e2b6/render HTTP/1.1" 404 1426 "https://ci.company.com/ci/job/abc-004-7/configure" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0"
172.17.2.152 - - [13/Aug/2014:08:47:17 +0200] "POST /ci/$stapler/bound/877daf46-3cda-4dee-93dc-f0138e0d6b58/render HTTP/1.1" 404 1426 "https://ci.company.com/ci/job/abc-004-7/configure" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0"
172.17.2.152 - - [13/Aug/2014:08:47:51 +0200] "POST /ci/$stapler/bound/3b0ac66b-e538-4db5-8e38-8d9234bd96c6/render HTTP/1.1" 404 1426 "https://ci.company.com/ci/job/abc-004-7/configure" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0"

172.17.2.152 - - [13/Aug/2014:08:49:45 +0200] "POST /ci/$stapler/bound/64ca65fd-d021-4d0a-9e50-f4d3184a02aa/render HTTP/1.1" 200 177 "http://myhost:8080/ci/job/abc-004-7/configure" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0"
172.17.2.152 - - [13/Aug/2014:08:49:45 +0200] "POST /ci/$stapler/bound/ee2f370a-6125-41e4-9061-9f110521fa05/render HTTP/1.1" 200 26 "http://myhost:8080/ci/job/abc-004-7/configure" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0"
172.17.2.152 - - [13/Aug/2014:08:49:58 +0200] "POST /ci/$stapler/bound/d7847927-9b59-497b-a19c-7186a4ddc653/render HTTP/1.1" 200 982 "http://myhost:8080/ci/job/abc-004-7/configure" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0"

There is no exception or error logged in jenkins.log.

I am seeing this fairly consistently, however, following Kohsuke's instructions to get some logging I am hitting:

Problem accessing /$stapler/bound/table/enableLogging. Reason:
java.lang.RuntimeException: java.io.NotSerializableException: org.kohsuke.stapler.bind.BoundObjectTable$Table

FWIW, I suspect the problem in (at least) my case is because the servlet container is configured to perform "session replication"-style serialization of the session objects, and the BoundObjectTable isn't Serializable.

we migrated Jenkins to 1.580.1 after migration we are unable to add any post build action ,even any drop down menu in job configuration is not working.
i tried the enabling log as suggested by Kohsuke's but not getting any message.

2Legacy checkUrl '/job/affinity-web-master/descriptorByName/jenkins.plugins.publish_over_ssh.BapSshTransfer/checkExecCommand' is not valid Javascript: SyntaxError: Invalid flags supplied to RegExp constructor 'affinity' hudson-behavior.js:419
XHR finished loading: GET "http://ewe.builds.sb.karmalab.net/job/affinity-web-master/descriptorByName/…fact.CopyArtifactPermissionProperty/checkProjectNames?value=&projectNames=". prototype.js:1585Ajax.Request.Class.create.request prototype.js:1585Ajax.Request.Class.create.initialize prototype.js:1550(anonymous function) prototype.js:452klass prototype.js:101FormChecker.sendRequest hudson-behavior.js:159FormChecker.schedule hudson-behavior.js:167FormChecker.delayedCheck hudson-behavior.js:150registerValidator hudson-behavior.js:436(anonymous function) behavior.js:111(anonymous function) behavior.js:107Behaviour.applySubtree behavior.js:93Behaviour.apply behavior.js:76(anonymous function) behavior.js:71window.onload behavior.js:125
POST http://ewe.builds.sb.karmalab.net/$stapler/bound/8383bd25-8d9d-4313-a821-ad4edb221bc9/render 404 (Not Found) prototype.js:1585Ajax.Request.Class.create.request prototype.js:1585Ajax.Request.Class.create.initialize prototype.js:1550(anonymous function) prototype.js:452klass prototype.js:101proxy.(anonymous function) bind.js:51renderOnDemand hudson-behavior.js:540updateDropDownList hudson-behavior.js:1103jenkinsRules.SELECT.dropdownList hudson-behavior.js:1118(anonymous function) behavior.js:111(anonymous function) behavior.js:107Behaviour.applySubtree behavior.js:93Behaviour.apply behavior.js:76(anonymous function) behavior.js:71window.onload behavior.js:125
XHR finished loading: POST "http://ewe.builds.sb.karmalab.net/$stapler/bound/8383bd25-8d9d-4313-a821-ad4edb221bc9/render". prototype.js:1585Ajax.Request.Class.create.request prototype.js:1585Ajax.Request.Class.create.initialize prototype.js:1550(anonymous function) prototype.js:452klass prototype.js:101proxy.(anonymous function) bind.js:51renderOnDemand hudson-behavior.js:540updateDropDownList hudson-behavior.js:1103jenkinsRules.SELECT.dropdownList hudson-behavior.js:1118(anonymous function) behavior.js:111(anonymous function) behavior.js:107Behaviour.applySubtree behavior.js:93Behaviour.apply behavior.js:76(anonymous function) behavior.js:71window.onload behavior.js:125
POST http://ewe.builds.sb.karmalab.net/$stapler/bound/0ff30232-ef2b-42e5-b26d-6beab66267ce/render 404 (Not Found) prototype.js:1585Ajax.Request.Class.create.request prototype.js:1585Ajax.Request.Class.create.initialize prototype.js:1550(anonymous function) prototype.js:452klass prototype.js:101proxy.(anonymous function) bind.js:51renderOnDemand hudson-behavior.js:540updateDropDownList hudson-behavior.js:1103jenkinsRules.SELECT.dropdownList hudson-behavior.js:1118(anonymous function) behavior.js:111(anonymous function) behavior.js:107Behaviour.applySubtree behavior.js:93Behaviour.apply behavior.js:76(anonymous function) behavior.js:71window.onload

same thing working fine if we use https but not working with http.
before using 1.580.1, both http and https working fine.

hridyeshpant I suspect your problem is an unrelated bug, perhaps in the Publish Over SSH plugin.

This occured to us when upgrading to 1.594 through `apt-get upgrade`.

Removing and then reinstalling jenkins through `apt-get remove jenkins && apt-get install jenkins` seems to have fixed the issue.

While investigating JENKINS-27311 I learned that Jenkins requires an active HttpSession / JSESSIONID cookie from the request. In that case, it was a mismatch between configured and actually used Jenkins URLs (which probably prevented the cookie from being set). So that's something to be aware of here.