This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
CVS update for continuous build process ends unssuccesfully with the following messages: cvs command: cvs co -A -D "2004-01-06 05:51 +0000" nbbuild openide openidex core java xml libs ant httpserver scripting tomcatint web U openide/api/doc/org/openide/doc-files/upgrade.html Terminated with fatal signal 11 Core dumped; preserving /tmp/cvs-serv23111 on server. CVS locks may need cleaning up. cvs command: cvs update -d -P -A -D "2004-01-06 05:51 +0000" ant applet autoupdate beans classfile clazz core db debuggercore debuggerjpda diff editor extbrowser form html httpserver i18n ide image j2eeserver jarpackager java javacvs javadoc jellytools jemmy junit libs monitor nbbuild openide openidex projects properties schema2beans tasklist text tomcatint ui usersguide utilities vcscore vcscvs vcsgeneric web xml xtest Terminated with fatal signal 11 Core dumped; preserving /tmp/cvs-serv23515 on server. CVS locks may need cleaning up.
Collab, can you take a look ASAP pls ? Thanks.
Looking into this and will update soon.
Filed an issue 25099 and paged operation engineer to look at this issue. Will update in other half an hour. Priya
Engineer looked at this and there is no locks. [kallen@s001 doc-files]$ pwd /var/run/cvslock/openide/api/doc/org/openide/doc-files [kallen@s001 doc-files]$ ls -la total 32 drwxr-xr-x 2 tigrisc tigris 117 Jan 5 23:31 . drwxr-xr-x 20 tigrisc tigris 1260 Jan 5 23:31 .. perhaps the cvscleanup script already took care of them and also the tmp files mentioned in the error output are not in /tmp. Jack: Can you please try again now and if you find this again please call us back. Thanks, Priya
It didn't say openide/api/doc/org/openide/doc-files is locked. The last error log from commands which have run recently: cvs command: cvs co -A -D "2004-01-06 07:30 +0000" nbbuild..... Terminated with fatal signal 11 Core dumped; preserving /tmp/cvs-serv11934 on server. CVS locks may need cleaning up. cvs command: cvs update -d -P -A -D "2004-01-06 07:30 +0000" ant.... Those messages are one hour older: cvs command: cvs co -A -D "2004-01-06 06:30 +0000" nbbuild.... Terminated with fatal signal 11 Core dumped; preserving /tmp/cvs-serv771 on server. CVS locks may need cleaning up. cvs command: cvs update -d -P -A -D "2004-01-06 06:30 +0000" ant.... cvs server: [22:35:45] waiting for tigrisc's lock in /cvs/core/execution/src/org/netbeans/core/execution/beaninfo cvs server: [22:36:15] obtained lock in /cvs/core/execution/src/org/netbeans/core/execution/beaninfo cvs server: [22:37:29] waiting for tigrisc's lock in /cvs/core/src/org/netbeans/core/compiler cvs server: [22:37:59] obtained lock in /cvs/core/src/org/netbeans/core/compiler cvs server: [22:38:06] waiting for tigrisc's lock in /cvs/core/src/org/netbeans/core/resources/plaf cvs server: [22:38:36] obtained lock in /cvs/core/src/org/netbeans/core/resources/plaf cvs server: [22:38:44] waiting for tigrisc's lock in /cvs/core/test/qa-functional/src/gui/windowsystem cvs server: [22:39:14] obtained lock in /cvs/core/test/qa-functional/src/gui/windowsystem cvs server: [22:42:18] waiting for tigrisc's lock in /cvs/j2eeserver/javahelp/org/netbeans/modules/j2ee cvs server: [22:42:48] obtained lock in /cvs/j2eeserver/javahelp/org/netbeans/modules/j2ee cvs server: [22:43:07] waiting for tigrisc's lock in /cvs/java/j2seplatform/src/org cvs server: [22:43:37] obtained lock in /cvs/java/j2seplatform/src/org cvs server: [22:43:58] waiting for tigrisc's lock in /cvs/java/test/unit/testsrc/org/netbeans/test/java/testsources/ifaces cvs server: [22:44:28] obtained lock in /cvs/java/test/unit/testsrc/org/netbeans/test/java/testsources/ifaces cvs server: [22:45:29] waiting for tigrisc's lock in /cvs/openide/src/org cvs server: [22:45:59] obtained lock in /cvs/openide/src/org Terminated with fatal signal 11 Core dumped; preserving /tmp/cvs-serv1155 on server. CVS locks may need cleaning up.
And the latest command failed again: cvs command: cvs update -d -P -A -D "2004-01-06 07:30 +0000" ant ... Terminated with fatal signal 11 Core dumped; preserving /tmp/cvs-serv12486 on server. CVS locks may need cleaning up.
Updated this to operation engineer. Awaiting the response.
Me and the ops engineer tried this again and we are not seeing the error you are seeing. If you reproduce this again we can see the remains in /tmp. Thanks, Priya
It is a continuous process. It tries to update sources in a loop. Now it is running the following: cvs command: cvs co -A -D "2004-01-06 09:28 +0000" nbbuild openide openidex core java xml libs ant httpserver scripting tomcatint web Terminated with fatal signal 11 Core dumped; preserving /tmp/cvs-serv11952 on server. CVS locks may need cleaning up. build script: update source: executing update of modules ant applet autoupdate beans classfile clazz core db debuggercore debuggerjpda diff editor extbrowser form html httpserver i18n ide image j2eeserver jarpackager java javacvs javadoc jellytools jemmy junit libs monitor nbbuild openide openidex projects properties schema2beans tasklist text tomcatint ui usersguide utilities vcscore vcscvs vcsgeneric web xml xtest cvs command: cvs update -d -P -A -D "2004-01-06 09:28 +0000" ant applet autoupdate beans classfile clazz core db debuggercore debuggerjpda diff editor extbrowser form html httpserver i18n ide image j2eeserver jarpackager java javacvs javadoc jellytools jemmy junit libs monitor nbbuild openide openidex projects properties schema2beans tasklist text tomcatint ui usersguide utilities vcscore vcscvs vcsgeneric web xml xtest cvs server: [01:38:16] waiting for tigrisc's lock in /cvs/j2eeserver/deprecated/src/org/netbeans/modules/j2ee/server cvs server: [01:38:46] obtained lock in /cvs/j2eeserver/deprecated/src/org/netbeans/modules/j2ee/server
Are you having this problem with other cvs modules you mentioned in the error context, such as "nbbuild" and "ant"?
and also * "what" is a continuous process? * is this a scripted process?or can they break down the actions into pieces to narrow down the problem?
and also * "what" is a continuous process? * is this a scripted process?or can you break down the actions into pieces to narrow down the problem?
I can reproduce this issue with command: cvs co -P -A -D "2003-06-01 09:28 +0000" ant core j2eeserver nbbuild openide it allways fails in different module/directory, so it's not bound to specific module(s), but the current server state (i.e. disk space in /tmp etc.)
The continuous process, Jirka is referring to, is just simple loop with body of "cvs checkout/update, do java build, deploy results, wait some time". The cvs operations part fails, so the other parts could not proceed for 9 hours already.
A "corrupt" file in the Attic was causing the core dump. Engr looked in the Attic for this problem and saw this: [kallen@s001 awt]$ ls -ltr Attic/ | tail -3 -r--r--r-- 1 tigrisc tigris 199400 Dec 18 17:24 Toolbar.java,v -r--r--r-- 1 tigrisc tigris 105788 Jan 5 17:13 HTMLRenderer.java,v -r--r--r-- 1 tigrisc tigris 79 Jan 5 17:15 HtmlRenderer.java,v I tried CO now, it is workinf fine. Please confrim this. - Priya
The issue is about case insensitivity.
Ops engineer fixed this issue by finding the case sensitive files in the Attic and once it is reomved it is working fine. First engr moved aside HTMLRenderer.java,v, tried to checkout, failed. Then moved aside, HtmlRenderer.java,v, tried to checkout, and succeeded. And i followed Rudolf's command, i can do CO without any interference. Rudolf: Please confirm from your side on this for the closure of the issue. -Priya
Tim, would you comment on this? Which file could be removed to fix corruption introduced by you case change? openide/src/org/openide/awt/HTMLRenderer.java,v or openide/src/org/openide/awt/HtmlRenderer.java,v My guess is that HtmlRender.java should be kept (what seems to be in oposite with current state according to CVSWEB http://www.netbeans.org/source/browse/openide/src/org/openide/awt/?showattic=1) Sripriya, it seems like the corrupted file is back (or still there?). I tried to checkout two files (command lines are probably wrapped to two lines). $ cvs co -P -A -D "2004-01-06 09:28 +0000" openide/src/org/openide/awt/HtmlRenderer.java Terminated with fatal signal 11 Core dumped; preserving /tmp/cvs-serv21514 on server. CVS locks may need cleaning up. $ $ $ cvs co -P -A -D "2004-01-06 09:28 +0000" openide/src/org/openide/awt/HTMLRenderer.java cvs server: warning: openide/src/org/openide/awt/HTMLRenderer.java is not (any longer) pertinent $
So that's what's going on. I've been trying to commit some changes to branch html_yet_again. One of the changes requested was that I rename HTMLRenderer.java to HtmlRenderer.java. I did that, and I guess that's what caused the problem. HtmlRenderer.java I would very much like to commit to the branch. HTMLRenderer.java is the old version of the same file. Can you let me know when it would be safe to add/commit HtmlRenderer.java, and if I should re-add it, or basically, what *exactly* I should do to put this file there on the branch html_yet_again *without* causing the problem again?
Suggestion: Remove all references to HtmlRenderer.java OR HTMLRenderer.java - as if it was never there. Let me know when that's done, and I'll add HtmlRenderer.java from my local copy. BTW, AFAIK unix file names are case sensitive - is our CVS server a Windows box or something, or is this just something CVS handles really badly?
CVS with a "local" repository on Linux certainly handles case variants in the same directory just fine; I tried it. Please let us know why your version of CVS chokes in this situation. BTW Tim - regardless of what the server can handle, don't ever create two files with case-variant names in the same dir if they are both live in a particular branch at once; Windows clients will get confused.
sripriya/support, is someone working on this issue? It's almost 5 hours since your last report an the issue is still there. Please follow 4 hours old suggestion from Tim Boudreau 2004-01-06 08:10 PST. If you cannot reproduce it, ensure, you do the cvs checkout with timestamp. The CVS server is unusable for timestamped checkouts/updates for more than 20 hours (issue is more than 13 hours old) and this night (prague time) is important milestone. Please fix it ASAP.
Support, pls respond. In Rudolf's update of 2004-01-06 07:29 PST (~8 hours old), he confirmed that the problem is NOT fixed. This is still a P1 issue.
Hi Jack, I just got a call from David Chan from NB's & I am working on it. I will update the issue within an hour. Eric
The offending file has been resolved. I have been asked by our operations team to not commit this one again or the same thing will happen. Thanks, Eric
Tim, Rudo, pls confirm. Thanks.
Eric, could you clarify this: > The offending file has been resolved. Resolved how? What did you do? > I have been asked by our operations team to not commit this one again > or the same thing will happen. I don't understand this. Do you mean I should not commit the same file again, or something else? The file, HtmlRenderer.java which caused the problem is part of a branch that will become part of NetBeans sources soon. So, I *do* need to put this file in CVS, on the branch html_yet_again. Will that cause the problem once again? Or is all trace of the file removed, as if it were never there, as I suggested, and it is now safe? Could you please clarify if it is safe to do so, or not, and what exactly you did to resolve the situation?
Sorry for the late. Actually there was problem here in my N/W. Ops engineer stated in the internal issue that she removed the corrupted file(HtmlRenderer.java) and asked NB not to commit it again bcos this will give the problem. Please check the update made on "sripriya 2004-01-06 03:26 PST". Now i can understand that you need this file HtmlRenderer.java only to be committed. What shall we do on this now? -Priya
Please simply remove HtmlRenderer.java and HTMLRenderer.java and any and all references to either file on the branch - I have a backup, so this is no problem. Just make it as if neither one ever existed or ever was put on the branch. Then it should be safe to commit the right file where it belongs. Thanks, Tim
I have updated the internal issue on this. I just want to confirm with you whether this task can be waited for some hours or need to be done immedietly. Priya
Re-opening this issue as it has not yet been resolved.
Here is an explanation of the core problem: Windows CVS clients request a service from the server when they first connect. The intent of this service is to prevent Windows clients from changing the capitalization of file names. This is necessary because, on the one hand, Windows programs and libraries often *do* change the capitalization of file names (and that's not supposed to matter, on Windows), and yet CVS (at least, if the server is Unix) can store both forms of the name. You can end up with, say foo.doc and foo.DOC being different files in CVS; the Windows clients can't update such a directory. The requested service is that the CVS server check, at such moments as "add", to be sure there are no case-insensitive name conflicts ("case conflicts"). If such an attempt is made, the request should be rejected. Note that this prevents *Windows* clients from creating this situation, but Unix clients can still do this freely (and, indeed, some popular Unix facilities depend upon it). Also note that this does not cause CVS to be case-insenstive, even in a completely Windows shop; it only refuses to be case-sensitive (rejects the operation), it doesn't "fix" things. There is, however, a bug in the CVS server code that implements this dubious service. The exact behavior of the bug doesn't make a whole lot of sense (that's kind of why we call it a bug!), but in essence what happens is this: there's a point in the code that's supposed to check for a case conflict, but that check is missing (that's the bug). There's a later point where some code assumes that check has already been made, and case conflicts would be rejected, and so this later code assumes there can't possibly be a case conflict. If there is a case conflict, this later code trips over it, crashes the CVS server, aborts the operation in progress, and leaves a truncated file in place which is the main symptom of the problem. We discovered (or at least, "unraveled") this situation in the last few months. CollabNet responded with a script that prevents anyone, under any circumstances, from creating a case conflict. This completely avoids the two code snippets mentioned above, that were confusing each other. However, our script goes a little overboard, in preventing all such cases. It was in fact initially installed on NetBeans but we were asked remove it (which means, every time this comes up, we have to find and remove another truncated ,v file). Meanwhile, we found that the open-source CVS had fixed this bug (where "fix" means "fixed that one missing check, so the offending operations are blocked"). This new version of CVS has been rolled into our product as of the 2.6.x versions. We whould advise all case changes to filenames be made from Unix or Macintosh clients, instead of from Windows. This will work to avoid corrupting the repository. ----------------------------------------------------------- I have asked operations to remove the both versions of the file as Tim has asked.
Both versions of the file have been removed. This should be resolved and explained now.
For me it seems to be resolved.
Brian, you stated: > It was in fact initially installed on NetBeans but we were asked > remove it would you please provide me with issue number to help me recall, what led to remove that feature? I'm not aware of the fact that it was ever fixed on live site. The only solution we were cooperating on (Sun w/ CollabNet) is in issue 17694, but am not sure it's related to that case you're talking about. In the issue 17694 is a reference to "Fixed in Truckee 1", but AFAIK, this version of SourceCast has not been rolled out to live site yet (correct me if I'm wrong).
You do not have truckee yet but the upgrade is scheduled to happen soon. Alas, I do not have an issue number corresponding to the script. I was conveying what an engineer had advised and figured you would know already about the situation. I can do some more digging into this if you would like. Please advise.
Brian, I would welcome, if you could dig into that and find some more details about status of the solution. Please check relation to that issue 17694 as well. Thanks
The engineers I have asked don't have an issue number to point to nor a more specific record of the installation of the aforementioned script. I don't believe it had to do with issue 17694 given the engineer who made the assertion regarding a script to avoid case conflicts was not with the company at the time that issue was active. I'm not sure where we go from here, can we resolve again? The symptoms have been taken care of and the new version of SC should address this as well.
Brian, I would like to know where the information about the fix came from. I'm not certain whether it was or was not installed. I just want you to come with an evidence or tell us it was not as accurate information. After that you can resolve.
It must be inaccurate information if there is no supporting documentation in our internal systems.
Resolving as I have met Rudolph's last request.
Verified.
Closing
We recently moved out from Collabnet's infrastructure