[JIRA] [dropdown-viewstabbar-plugin] (JENKINS-33432) upgrading dropdown views tabbar to 1.7 results in hang while displaying listview
Title: Message Title Jay Berkenbilt created an issue Jenkins / JENKINS-33432 upgrading dropdown views tabbar to 1.7 results in hang while displaying listview Issue Type: Bug Assignee: Unassigned Attachments: plugins.tsv, stacktrace.txt Components: dropdown-viewstabbar-plugin Created: 09/Mar/16 6:22 PM Environment: Ubuntu 14.04 LTS with 1.642.2 debian package; Oracle Java 1.8u45. Installed plugin list attached. Priority: Minor Reporter: Jay Berkenbilt Our Jenkins installation has over 75K jobs and about 1600 views. Upon upgrading the dropdown views tabbar plugin from 1.6 to 1.7, any attempt to retrieve the contents of a view through the web UI would hang. The attached stack trace is from a thread dump of Jenkins while trying to get the contents of a view by just visiting the main page. Other operations within Jenkins, such as going directly to a job or build or to the configuration interface work fine. We observe this behavior with or without the option to show job counts. We also verified that we see the same
[JIRA] [xvnc-plugin] (JENKINS-25424) Exception when editing nodes
Jay Berkenbilt commented on JENKINS-25424 Exception when editing nodes I still intend to try to provide detailed instructions for reproducing the problem, but the fact that people are able to work around it by removing this property seems to suggest that my original theory may be correct: once the node is used one time to run a job that uses the Xvnc plugin, this property appears, and after the property is there, configuration of the node fails in this way. I'll see if that formula works on a clean install. Removing properties and reloading is not a practical workaround for my installation. We scale up and down from between a small handful to several hundred nodes and are constantly churning through nodes. Reloading configuration from disk is not practical for us. In any case, since we churn through nodes, I'm not heavily handicapped by this. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [xvnc-plugin] (JENKINS-25424) Exception when editing nodes
Jay Berkenbilt reopened JENKINS-25424 Exception when editing nodes I don't think the fix was complete. After applying the fix and restarting, I am still seeing this behavior on slaves starting after they have run Xvnc. If you aren't seeing it, I will try to create a quick formula for reproducing it. We're running the latest LTS. Change By: Jay Berkenbilt (13/Nov/14 3:40 PM) Resolution: Fixed Status: Resolved Reopened This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [prioritysorter] (JENKINS-24618) Absolute priority not working
Jay Berkenbilt commented on JENKINS-24618 Absolute priority not working I'm finding priorities ignored in absolute mode as well. I did essentially the same test: vanilla install of Jenkins with only the priority queue sorter, one executor, three jobs that sleep. I see the same thing: jobs are run in fifo order. I would love to know what configuration area Markus had and whether Thomas Westling is still seeing the problem. I'm running 1.565.2 (LTS) and plugin 2.8. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-23798) Accessing certain list views fails with null pointer issues
Jay Berkenbilt created JENKINS-23798 Accessing certain list views fails with null pointer issues Issue Type: Bug Assignee: Unassigned Components: core Created: 15/Jul/14 2:52 PM Description: We started seeing this when we upgraded to 1.532.3, and we don't know how to reproduce it. Frequently we see cases where a particular view's jobs can't be listed. Calls to view.getItems() or attempts to look at the view in the UI (/view/viewName/?) fail. Here's a sample stack trace: Caught exception evaluating: it.items in /view/KevinClaudius_record-news-link/. Reason: java.lang.reflect.InvocationTargetException java.lang.reflect.InvocationTargetException at sun.reflect.GeneratedMethodAccessor359.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.commons.jexl.util.PropertyExecutor.execute(PropertyExecutor.java:125) at org.apache.commons.jexl.util.introspection.UberspectImpl$VelGetterImpl.invoke(UberspectImpl.java:314) at org.apache.commons.jexl.parser.ASTArrayAccess.evaluateExpr(ASTArrayAccess.java:185) at org.apache.commons.jexl.parser.ASTIdentifier.execute(ASTIdentifier.java:75) at org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:83) at org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:57) at org.apache.commons.jexl.parser.ASTReferenceExpression.value(ASTReferenceExpression.java:51) at org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:80) at hudson.ExpressionFactory2$JexlExpression.evaluate(ExpressionFactory2.java:74) at org.apache.commons.jelly.tags.core.CoreTagLibrary$3.run(CoreTagLibrary.java:134) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:99) at org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.tags.core.CoreTagLibrary$1.run(CoreTagLibrary.java:98) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105) at org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:120) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:99) at org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105) at org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:120) at org.kohsuke.stapler.jelly.CompressTag.doTag(CompressTag.java:44) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269) at org.kohsuke.stapler.jelly.JellyViewScript.run(JellyViewScript.java:81) at org.kohsuke.stapler.jelly.DefaultScriptInvoker.invokeScript(DefaultScriptInvoker.java:63) at org.kohsuke.stapler.jelly.DefaultScriptInvoker.invokeScript(DefaultScriptInvoker.java:53) at
[JIRA] [core] (JENKINS-17999) deadlock in 1.509.1 deleting multiple jobs with REST API
Jay Berkenbilt closed JENKINS-17999 as Duplicate deadlock in 1.509.1 deleting multiple jobs with REST API This bug is no longer reproducible starting with 1.509.4. It looks like the commit 5407d9fbce6b10d6902f0cc5971ee95c71619f3a, cherry picked from 7facc7733c7040536d4074a2c5805b75ee1d8f35, which was to fix JENKINS-18589 also solved this problem. I have confirmed that I can easily reproduce the problem with 1.509.1 and can no longer reproduce it with 1.509.4. It also looks like the parameterized trigger plugin, which was then at 2.17 and is currently at 2.24, has a different code path as well. As the reporter, I'm closing this issue since I believe it no longer exists. Change By: Jay Berkenbilt (25/Apr/14 3:59 PM) Status: Open Closed Resolution: Duplicate This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-17999) deadlock in 1.509.1 deleting multiple jobs with REST API
Jay Berkenbilt created JENKINS-17999 deadlock in 1.509.1 deleting multiple jobs with REST API Issue Type: Bug Assignee: Unassigned Components: core Created: 17/May/13 3:16 PM Description: While I left the priority at "Major", this problem prevents us from being able to run 1.509.1. We had to downgrade back to 1.480.3. High-level description: When deleting multiple jobs using the REST API with 1.509.1, we get a reliable deadlock that results in our having to restart Jenkins. This happens often in our environment, so we have had to downgrade to 1.480.3 for now after less than a day on 1.509.1. The stack trace passes through hudson.plugins.parameterizedtrigger.Plugin$RenameListener.onDeleted(Plugin.java:66) but I don't know whether that's part of the issue or whether it's just getting there first. The jobs being deleted share a view and include junit test result aggregation from an upstream job that is also being deleted. I have not determined whether the jobs have to be related for this problem to occur. Detailed description: Our Jenkins instance has thousands of jobs (over 6,000 at last check). We scale up and down in number of slaves during the day but usually peak at about 200+ slaves. Developers work on branches in git. When a developer pushes changes to a new branch, we create a compile job and a series of downstream test jobs. The compile job runs with every push to the branch, and when the compile job succeeds, it kicks off the test jobs, which run in parallel. All the jobs are in a single view. The mechanism by which the test jobs are kicked off is with a system groovy script that finds other jobs in the view. When the branch is deleted, a hook queries to get the list of jobs in the view and POSTs to /job/job-name/doDelete for each job to cause its deletion. Then it deletes the view. We've been operating this way for many months, and we have run several consecutive recent LTS versions. When we upgraded to 1.509.1, it only took one occurrence of the bulk job deletion to lock Jenkins up so that it was unresponsive to HTTP requests. Other aspects of Jenkins continued to operate...tailing the log revealed that the queue was still being serviced, jobs were still finishing and archiving results, etc. However, Jenkins is clearly not usable in this state, so we had to restart to restore normal operation. While we were running 1.480, we occasionally saw a similar problem where Jenkins stopped service HTTP requests but otherwise appeared to be operating normally. I think we only saw it 2 or maybe 3 times since upgrading to 1.480. We are hoping to report an issue about it, but we still don't have anything to go on. I realize that the number of HTTP request handling threads went from 1000 to 20, which means that an operation that deadlocked 20ish threads would lock up Jenkins right away now and might have taken longer before, but a few observations make me guess that we have not seen this particular failure before. In particular, I'm sure that branch deletion was working before and is once again working now that we have downgraded back to 1.480.3. Here's the somewhat abbreviated deadlock section of the jstack output with the job names replaced consistently. I would have to do some sanitizing before I could post the full thread dumps, but I will save them in case it should be necessary. Found one Java-level deadlock: = "Handling POST /job/--JOB1--/doDelete : RequestHandlerThread[#246]": waiting to lock monitor 0x7fda48602188 (object 0x0005f7726ac0, a hudson.model.FreeStyleProject), which is held by "Handling POST /job/--JOB2--/doDelete : RequestHandlerThread[#213]" "Handling POST /job/--JOB2--/doDelete : RequestHandlerThread[#213]": waiting to lock monitor 0x7fda48e56890 (object 0x0005f7726790, a hudson.model.FreeStyleProject), which is held by "Handling POST /job/--JOB3--/doDelete : RequestHandlerThread[#210]" "Handling POST /job/--JOB3--/doDelete : RequestHandlerThread[#210]": waiting to lock monitor 0x7fda48602188 (object 0x0005f7726ac0, a
[JIRA] (JENKINS-13417) git-plugin: rev-parse dereferencing tags breaks on Windows
[
https://issues.jenkins-ci.org/browse/JENKINS-13417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=161831#comment-161831
]
Jay Berkenbilt commented on JENKINS-13417:
--
The exact behavior of how rev^{commit} is interpreted seems to depend on
several factors including whether git is invoked by explicit path or by being
found in %PATH% and whether it is cygwin or not. For the case of git being
invoked by explicit path, the ^ doesn't disappear. My workaround, for now, to
avoid downgrading to 1.1.15, is to compile this C program:
{code}
#include stdio.h
#include string.h
#include stdlib.h
int needs_quotes(char* arg)
{
if (strchr(arg, ' ') ||
strchr(arg, '^') ||
strchr(arg, '[') ||
strchr(arg, ']') ||
strchr(arg, '{') ||
strchr(arg, '}') ||
strchr(arg, '*') ||
strchr(arg, '?'))
{
return 1;
}
return 0;
}
int main(int argc, char* argv[])
{
int i;
int cmdlen = 0;
char* newcmd = 0;
char* git = C:\\cygwin\\bin\\git.exe;
cmdlen += strlen(git) + 1;
for (i = 1; i argc; ++i)
{
cmdlen += strlen(argv[i]) + 1;
if (needs_quotes(argv[i]))
{
/* add characters for quotation marks */
cmdlen += 2;
}
}
newcmd = malloc(cmdlen);
strcpy(newcmd, git);
for (i = 1; i argc; ++i)
{
strcat(newcmd, );
if (needs_quotes(argv[i]))
{
strcat(newcmd, \);
strcat(newcmd, argv[i]);
strcat(newcmd, \);
}
else
{
strcat(newcmd, argv[i]);
}
}
return system(newcmd);
}
{code}
to git-wrapper.exe using mingw (so it doesn't have any cygwin in it) and to
install it in C:\cygwin\bin\git-wrapper.exe. Then I set up a git executable in
the general Jenkins configuration called windows-git-wrapper with the
executable as C:\cygwin\bin\git-wrapper.exe, and make that the git that I use
in Windows jobs. That particular formula works fine for regular jobs tied to
git as well as for building parameterized downstream jobs and passing the git
commit through. All the above code does is put double quotes around arguments
that have special characters in them.
I'm not sure what the correct fix to the git plugin would be since it seems
like it would have to detect too many things to know what it needs to do.
However, perhaps putting double quotes around the argument to rev-parse may be
sufficient for Windows and may probably be harmless, though I haven't tested it
in under other conditions. Ultimately it seems like the code should work for
both cygwin and non-cygwin git.exe both in %PATH% and executed by explicit path.
git-plugin: rev-parse dereferencing tags breaks on Windows
--
Key: JENKINS-13417
URL: https://issues.jenkins-ci.org/browse/JENKINS-13417
Project: Jenkins
Issue Type: Bug
Components: git
Environment: Windows 2008 R2 slave launched with cygwin ssh, cygwin
git
Reporter: Jay Berkenbilt
Assignee: Nicolas De Loof
The change to GitAPI.java in commit 13f6038acc4fa5b5a62413155da6fc8cfcad3fe0
seems to break the git plugin for Windows, at least in some circumstances.
The syntax rev^{commit} gets mangled by cmd because ^ is a quote character.
This means that cmd passes rev{commit} to git, which as a cygwin executable
being run from Windows, further tries to do wildcard expansion and maps this
to revcommit. Putting around rev^{commit} empirically seems to work,
though I haven't tried it in the git plugin itself.
This C fragment:
{code}
#include stdio.h
int main(int argc, char* argv[])
{
int i;
for (i = 0; i argc; ++i)
{
printf(%s\n, argv[i]);
}
return 0;
}
{code}
when compiled with mingw to a native Windows application (a.exe) and invoked
from cmd as a.exe a^{b} prints a{b}. When the same fragment is compiled with
cygwin gcc to cygwin executable a.exe and is invoked the same way from cmd,
it prints ab. Both print a^{b} when invoked from cmd as a.exe a^{b}.
I'm not sure what the fix is here other than perhaps detecting that this is
windows and putting quotes around the argument in Windows.
On another note, I left the Affects Version/s field blank. My Jenkins
installation claims that it is using version 1.1.6. Looking at the git repo
for the plugin, it appears that 1.1.6 should not have the ^{commit} fix, yet
running strings on
plugins/git/WEB-INF/classes/hudson/plugins/git/GitAPI.class clearly shows
that my git plugin has that change in it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
[JIRA] (JENKINS-13417) git-plugin: rev-parse dereferencing tags breaks on Windows
Jay Berkenbilt created JENKINS-13417:
Summary: git-plugin: rev-parse dereferencing tags breaks on Windows
Key: JENKINS-13417
URL: https://issues.jenkins-ci.org/browse/JENKINS-13417
Project: Jenkins
Issue Type: Bug
Components: git
Environment: Windows 2008 R2 slave launched with cygwin ssh, cygwin git
Reporter: Jay Berkenbilt
Assignee: Nicolas De Loof
The change to GitAPI.java in commit 13f6038acc4fa5b5a62413155da6fc8cfcad3fe0
seems to break the git plugin for Windows, at least in some circumstances. The
syntax rev^{commit} gets mangled by cmd because ^ is a quote character. This
means that cmd passes rev{commit} to git, which as a cygwin executable being
run from Windows, further tries to do wildcard expansion and maps this to
revcommit. Putting around rev^{commit} empirically seems to work, though I
haven't tried it in the git plugin itself.
This C fragment:
{code}
#include stdio.h
int main(int argc, char* argv[])
{
int i;
for (i = 0; i argc; ++i)
{
printf(%s\n, argv[i]);
}
return 0;
}
{code}
when compiled with mingw to a native Windows application (a.exe) and invoked
from cmd as a.exe a^{b} prints a{b}. When the same fragment is compiled with
cygwin gcc to cygwin executable a.exe and is invoked the same way from cmd, it
prints ab. Both print a^{b} when invoked from cmd as a.exe a^{b}.
I'm not sure what the fix is here other than perhaps detecting that this is
windows and putting quotes around the argument in Windows.
On another note, I left the Affects Version/s field blank. My Jenkins
installation claims that it is using version 1.1.6. Looking at the git repo
for the plugin, it appears that 1.1.6 should not have the ^{commit} fix, yet
running strings on plugins/git/WEB-INF/classes/hudson/plugins/git/GitAPI.class
clearly shows that my git plugin has that change in it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13417) git-plugin: rev-parse dereferencing tags breaks on Windows
[
https://issues.jenkins-ci.org/browse/JENKINS-13417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=161483#comment-161483
]
Jay Berkenbilt commented on JENKINS-13417:
--
In case anyone is searching for this, I should mention that this problem
manifests itself as this error message in the build output:
ERROR: Couldn't find any revision to build. Verify the repository and branch
configuration for this job.
This is because the command git rev-parse mastercommit (in the case of the
default, which is to use the master branch) is failing.
git-plugin: rev-parse dereferencing tags breaks on Windows
--
Key: JENKINS-13417
URL: https://issues.jenkins-ci.org/browse/JENKINS-13417
Project: Jenkins
Issue Type: Bug
Components: git
Environment: Windows 2008 R2 slave launched with cygwin ssh, cygwin
git
Reporter: Jay Berkenbilt
Assignee: Nicolas De Loof
The change to GitAPI.java in commit 13f6038acc4fa5b5a62413155da6fc8cfcad3fe0
seems to break the git plugin for Windows, at least in some circumstances.
The syntax rev^{commit} gets mangled by cmd because ^ is a quote character.
This means that cmd passes rev{commit} to git, which as a cygwin executable
being run from Windows, further tries to do wildcard expansion and maps this
to revcommit. Putting around rev^{commit} empirically seems to work,
though I haven't tried it in the git plugin itself.
This C fragment:
{code}
#include stdio.h
int main(int argc, char* argv[])
{
int i;
for (i = 0; i argc; ++i)
{
printf(%s\n, argv[i]);
}
return 0;
}
{code}
when compiled with mingw to a native Windows application (a.exe) and invoked
from cmd as a.exe a^{b} prints a{b}. When the same fragment is compiled with
cygwin gcc to cygwin executable a.exe and is invoked the same way from cmd,
it prints ab. Both print a^{b} when invoked from cmd as a.exe a^{b}.
I'm not sure what the fix is here other than perhaps detecting that this is
windows and putting quotes around the argument in Windows.
On another note, I left the Affects Version/s field blank. My Jenkins
installation claims that it is using version 1.1.6. Looking at the git repo
for the plugin, it appears that 1.1.6 should not have the ^{commit} fix, yet
running strings on
plugins/git/WEB-INF/classes/hudson/plugins/git/GitAPI.class clearly shows
that my git plugin has that change in it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
