date:20030227

RE: Lock contention executing cvs log

2003-02-27 Thread MacDonald, Ian

This is a follow up with some more observations:

While several of my build processes were running, I was monitoring the CVS
server with 'top'.  I noticed a strange occurrence with two of cvs processes
that were currently executing a log command - both processes grew to consume
nearly all available memory (in my case 512MB).  While this was occurring,
the cvs clients associated with these growing cvs processes started dumping
the 'waiting for blahs lock' messages to stdout.  This went on for about 15
minutes before the log commands completed.  Does anyone know if this is
normal behavior?

BTW, in case you're curious, the log command is running against a source
tree with ~1.5 GB of mixed binary and text source files.  I think the
biggest binary file is ~30MB.

Regards,

-- Ian MacDonald


-Original Message-
From: MacDonald, Ian [mailto:[EMAIL PROTECTED] 
Sent: Thursday, February 27, 2003 12:10 PM
To: '[EMAIL PROTECTED]'
Subject: Lock contention executing cvs log


Hi Folks, 
I'm sorry if this posting might appear twice.  I first posted this to the
NNTP group gnu.cvs.help but was not sure my posts were actually making it.
Here's my problem: 
We have an automated build environment (CruiseControl) running on multiple
hosts that poll for changes in a cvs repository using the cvs log command.
We are seeing a
problem that seems to be resulting in an inordinate amount of time executing

the log command. 
When to two or more of the hosts are executing "cvs -q log -N -d upperdate >

Lowerdate -b" on the same module they seem to get stuck in a lockstep mode
of 
waiting for each others locks with each module taking upwards of a 
minute.  For our respository this adds up to 30 minutes to each build cycle
scanning for changes. 
Shouldn't cvs simply be using "read" locks while executing the log command? 
If that's the case, why is there a contention for the "read" locks?  Perhaps
there is a write lock getting created? 
Any assistance would be appreciated. 
Thanks, 
-- Ian MacDonald 


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Restrict tag creation rights.

2003-02-27 Thread Larry Jones

Alexandre Augusto Drummond Barroso writes:
> 
> It doesn't work (at least until 1.11.2 - I don't know if it has been
> changed in new versions already released). It seams CVS doesn't care 
> about return code of a program called through taginfo.

I cannot reproduce your problem -- it works just fine for me in 1.11.1p1.

-Larry Jones

In short, open revolt and exile is the only hope for change? -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: Restrict tag creation rights.

2003-02-27 Thread Alexandre Augusto Drummond Barroso

It doesn't work (at least until 1.11.2 - I don't know if it has been
changed in new versions already released). It seams CVS doesn't care 
about return code of a program called through taginfo.
Non-zero exit return code works fine for commitinfo and and other hooks, 
except for taginfo (I had already posted something about it six months 
ago with no solution).

Cheers,

Xandao.

> -Original Message-
> From: Ralf S. Engelschall [mailto:[EMAIL PROTECTED]
> Sent: Thursday, February 27, 2003 9:41 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Restrict tag creation rights.
> 
> 
> On Wed, Feb 26, 2003, Nitin Dube wrote:
> 
> > In CVS, is it possible to restrict the rights create a tag only to
> > certain users?
> > If it is possible, please guide me as to how can this be done?
> 
> It is possible through the $CVSROOT/CVSROOT/taginfo.
> See the CVS manual for more details on how to use those hooks, please.
> 
>Ralf S. Engelschall
>[EMAIL PROTECTED]
>www.engelschall.com
> 

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Lock contention executing cvs log

2003-02-27 Thread MacDonald, Ian

Title: Lock contention executing cvs  log





Hi Folks,


I'm sorry if this posting might appear twice.  I first posted this to the NNTP group gnu.cvs.help but was not sure my posts were actually making it.

Here's my problem:


We have an automated build environment (CruiseControl) running on multiple hosts that poll for changes in a cvs repository using the cvs log command.  We are seeing a

problem that seems to be resulting in an inordinate amount of time executing
the log command.


When to two or more of the hosts are executing "cvs -q log -N -d upperdate >
Lowerdate -b" on the same module they seem to get stuck in a lockstep mode of
waiting for each others locks with each module taking upwards of a
minute.  For our respository this adds up to 30 minutes to each build cycle scanning for changes.


Shouldn't cvs simply be using "read" locks while executing the log command?
If that's the case, why is there a contention for the "read" locks?  Perhaps there is a write lock getting created?


Any assistance would be appreciated.


Thanks,


-- Ian MacDonald



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

One of my CVS users is reporting conflicts on unchanged files afterrunning "cvs up -dP"....

2003-02-27 Thread Tom Copeland

...it seems to happen at more or less random intervals.  He's using a
1.12 Linux client to talk to a 1.15 Linux server using :ext:.

Has anyone else experienced this behavior?

Thanks,

Tom Copeland
InfoEther
703-486-4543 



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: pserver core dumps on WinCVS login

2003-02-27 Thread Larry Jones

[EMAIL PROTECTED] writes:
> 
> Looks like recursive death may have been the whole problem. Now I get no
> core dumps, although an empty directory (cvs-servNN, where NN is
> the process ID for the server) is left in /tmp (not a big deal)...

No, something is going badly wrong somewhere.  You should have gotten an
error message at the client but, if not, then please try writing a short
shell script that runs the CVS server with stderr redirected into a
file, something like:

#! /bin/sh
exit /usr/local/bin/cvs "$@" 2>/tmp/cvs$$.log

temporarily change your inetd.conf to run the script rather than running
the server directly, reproduce the problem, and check the log file.

-Larry Jones

Hey Doc, for 10 bucks I'll make sure you see those kids in the
waiting room again real soon! -- Calvin

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: pserver core dumps on WinCVS login

2003-02-27 Thread MChojnacki


Looks like recursive death may have been the whole problem. Now I get no
core dumps, although an empty directory (cvs-servNN, where NN is
the process ID for the server) is left in /tmp (not a big deal)...

Thanks for the fix!

Mark Chojnacki
[EMAIL PROTECTED]
---


   
   
[EMAIL PROTECTED] (Larry Jones)
  
Sent by:To: [EMAIL 
PROTECTED] 
info-cvs-bounces+mchojnacki=symcor.ccc: [EMAIL 
PROTECTED]  
[EMAIL PROTECTED]  Subject: 
Re: pserver core dumps on WinCVS login   
   
   
   
   
02/27/03 12:54 PM  
   
   
   
   
   




[EMAIL PROTECTED] writes:
>
> Sorry about that. Here's the first few lines of output for the where
> command within dbx. The final 10 lines are repeated ad nauseum after
> that...

The following patch should avoid the recursive death, maybe then we'll
be able to figure out the root problem.

Index: server.c
===
RCS file: /cvs/ccvs/src/server.c,v
retrieving revision 1.284.2.1
diff -u -r1.284.2.1 server.c
--- server.c 21 Feb 2003 21:32:55 -  1.284.2.1
+++ server.c 27 Feb 2003 17:53:02 -
@@ -4863,8 +4863,13 @@
 server_cleanup (sig)
 int sig;
 {
 int status;
 int save_noexec;
+static int already_in_cleanup = 0;
+
+/* Make sure we don't get called recursively.  */
+if (already_in_cleanup) return;
+already_in_cleanup = 1;

 if (buf_to_net != NULL)
 {

-Larry Jones

It's hard to be religious when certain people are never
incinerated by bolts of lightning. -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs






___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: pserver core dumps on WinCVS login

2003-02-27 Thread Larry Jones

[EMAIL PROTECTED] writes:
> 
> Sorry about that. Here's the first few lines of output for the where
> command within dbx. The final 10 lines are repeated ad nauseum after
> that...

The following patch should avoid the recursive death, maybe then we'll
be able to figure out the root problem.

Index: server.c
===
RCS file: /cvs/ccvs/src/server.c,v
retrieving revision 1.284.2.1
diff -u -r1.284.2.1 server.c
--- server.c21 Feb 2003 21:32:55 -  1.284.2.1
+++ server.c27 Feb 2003 17:53:02 -
@@ -4863,8 +4863,13 @@
 server_cleanup (sig)
 int sig;
 {
 int status;
 int save_noexec;
+static int already_in_cleanup = 0;
+
+/* Make sure we don't get called recursively.  */
+if (already_in_cleanup) return;
+already_in_cleanup = 1;
 
 if (buf_to_net != NULL)
 {

-Larry Jones

It's hard to be religious when certain people are never
incinerated by bolts of lightning. -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Info-cvs Digest, Vol 3, Issue 42

2003-02-27 Thread Larry Jones

Douglas Finkle writes:
> 
> The fix should, IMHO, be applied to the server. Maybe this feature 
> (cvswrappers MERGE directive) is what CVS developers had intended
> to do, but have not yet fully implemented. I wish some of them
> would kindly speak up. :-)

I hate to encourage anyone to use the wrappers functionality, but here
is a patch that attempts to allow wrappers to specify MERGE for binary
files.  It should also allow merge options to work in client/server
mode.  Feel free to test and report back.
 
Index: cvs.h
===
RCS file: /cvs/ccvs/src/cvs.h,v
retrieving revision 1.241
diff -u -r1.241 cvs.h
--- cvs.h   25 Feb 2003 22:02:13 -  1.241
+++ cvs.h   27 Feb 2003 16:26:02 -
@@ -876,6 +876,7 @@
 char *wrap_rcsoption PROTO ((const char *fileName, int asFlag));
 char *wrap_tocvs_process_file PROTO((const char *fileName));
 int   wrap_merge_is_copy PROTO((const char *fileName));
+int   wrap_merge_is_merge PROTO((const char *fileName));
 void wrap_fromcvs_process_file PROTO ((const char *fileName));
 void wrap_add_file PROTO((const char *file,int temp));
 void wrap_add PROTO((char *line,int temp));
Index: update.c
===
RCS file: /cvs/ccvs/src/update.c,v
retrieving revision 1.204
diff -u -r1.204 update.c
--- update.c9 Feb 2003 04:13:28 -   1.204
+++ update.c27 Feb 2003 16:26:05 -
@@ -2003,8 +2003,8 @@
 copy_file (finfo->file, backup);
 xchmod (finfo->file, 1);
 
-if (strcmp (vers->options, "-kb") == 0
-   || wrap_merge_is_copy (finfo->file)
+if ((strcmp (vers->options, "-kb") == 0 ? !wrap_merge_is_merge (finfo->file)
+   : wrap_merge_is_copy (finfo->file))
|| special_file_mismatch (finfo, NULL, vers->vn_rcs))
 {
/* For binary files, a merge is always a conflict.  Same for
@@ -2165,14 +2165,16 @@
 char *jdate1;
 char *jdate2;
 
-TRACE ( 1, "join_file(%s, %s%s%s%s, %s, %s)",
-   finfo->file,
-   vers->tag ? vers->tag : "",
-   vers->tag ? " (" : "",
-   vers->vn_rcs ? vers->vn_rcs : "",
-   vers->tag ? ")" : "",
-   join_rev1 ? join_rev1 : "",
-   join_rev2 ? join_rev2 : "" );
+if (trace)
+   fprintf (stderr, "%s-> join_file(%s, %s%s%s%s, %s, %s)\n",
+   CLIENT_SERVER_STR,
+   finfo->file,
+   vers->tag ? vers->tag : "",
+   vers->tag ? " (" : "",
+   vers->vn_rcs ? vers->vn_rcs : "",
+   vers->tag ? ")" : "",
+   join_rev1 ? join_rev1 : "",
+   join_rev2 ? join_rev2 : "");
 
 jrev1 = join_rev1;
 jrev2 = join_rev2;
@@ -2524,8 +2526,8 @@
 
/* Avoid this in the text file case.  See below for why.
 */
-   && (strcmp (t_options, "-kb") == 0
-   || wrap_merge_is_copy (finfo->file)))
+   && (strcmp (t_options, "-kb") == 0 ? !wrap_merge_is_merge (finfo->file)
+  : wrap_merge_is_copy (finfo->file)))
 {
/* FIXME: Verify my comment below:
 *
@@ -2567,8 +2569,8 @@
   print.  */
write_letter (finfo, 'U');
 }
-else if (strcmp (t_options, "-kb") == 0
-|| wrap_merge_is_copy (finfo->file)
+else if ((strcmp (t_options, "-kb") == 0 ? !wrap_merge_is_merge (finfo->file)
+   : wrap_merge_is_copy (finfo->file))
 || special_file_mismatch (finfo, rev1, rev2))
 {
/* We are dealing with binary files, or files with a
Index: wrapper.c
===
RCS file: /cvs/ccvs/src/wrapper.c,v
retrieving revision 1.31
diff -u -r1.31 wrapper.c
--- wrapper.c   23 May 2002 18:13:17 -  1.31
+++ wrapper.c   27 Feb 2003 16:26:05 -
@@ -170,11 +170,6 @@
   and (more importantly) where we found it.  */
error (0, 0, "\
 -t and -f wrapper options are not supported remotely; ignored");
-   if (wrap_list[i]->mergeMethod == WRAP_COPY)
-   /* For greater studliness we would print the offending option
-  and (more importantly) where we found it.  */
-   error (0, 0, "\
--m wrapper option is not supported remotely; ignored");
send_to_server ("Argument -W\012Argument ", 0);
send_to_server (wrap_list[i]->wildCard, 0);
send_to_server (" -k '", 0);
@@ -182,6 +177,11 @@
send_to_server (wrap_list[i]->rcsOption, 0);
else
send_to_server ("kv", 0);
+   if (wrap_list[i]->mergeMethod !=
+   (wrap_list[i]->rcsOption && wrap_list[i]->rcsOption[0] == 'b')
+   ? WRAP_COPY : WRAP_MERGE)
+   send_to_server (wrap_list[i]->mergeMethod == WRAP_COPY ?
+   "' -m 'COPY" : "' -m 'MERGE", 0);
send_to_server ("'\012", 0);
 }
 }
@

Re: Checkout problem on cvs host

2003-02-27 Thread Larry Jones

Craig Dickson writes:
> 
> C:\dev\test\MAIN>cvs checkout -d . test
> cvs server: existing repository /usr/local/cvsroot does not match
> /usr/local/cvsroot/test
> cvs server: ignoring module test
> 
> Is this what is expected?

Yes, in client/server mode; I believe it works correctly in local mode. 
Is it correct?  No.  Has it been a big enough problem for anyone to try
to figure out why it happens and fix it?  No.

-Larry Jones

I hate being good. -- Calvin

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS on Solaris 2.8

2003-02-27 Thread Larry Jones

Amit Sharma writes:
> 
>   I have installed CVS 1.11.5 on Solaris2.8 but getting a strange
> problem while logging onto Server
> cvs [login aborted]: recv() from server 10.91.208.12: EOF

Either something's wrong with your inetd.conf -- it can't start the CVS
server or it's immediately dying -- or you have some kind of access
controls (like tcpwrappers) denying access to it.  Check your syslog for
error messages and see the CVS manual for more troubleshooting advice:

http://www.cvshome.org/docs/manual/cvs_21.html#SEC184>

-Larry Jones

That gives me a FABULOUS idea. -- Calvin

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: pserver core dumps on WinCVS login

2003-02-27 Thread MChojnacki


Sorry about that. Here's the first few lines of output for the where
command within dbx. The final 10 lines are repeated ad nauseum after
that...

catopen.expand_catname(0xf0b12078, 0x1, 0x0) at 0xd01895b0
catopen.catopen(??, ??) at 0xd018a474
assert.__assert(??, ??, ??) at 0xd02257e8
buffer.stdio_buffer_shutdown(0x2002d728), line 1384 in "buffer.c"
buffer.buf_shutdown(0x2002d728), line 1207 in "buffer.c"
server.server_cleanup(0x0), line 4885 in "server.c"
error.error_exit(), line 71 in "error.c"
error.error(0x1, 0x0, 0x2934, 0x26f8, 0x1001b514, 0xd0b2,
0xe6009b00, 0x2ff3af50), line 212 in "error.c"
main.main_cleanup(sig = 6), line 389 in "main.c"
sighandle.SIG_handle(0x6), line 158 in "sighandle.c"
abort.abort() at 0xd017f294
assert.__assert(??, ??, ??) at 0xd02259fc
buffer.stdio_buffer_shutdown(0x2002d728), line 1384 in "buffer.c"
buffer.buf_shutdown(0x2002d728), line 1207 in "buffer.c"
server.server_cleanup(0x0), line 4885 in "server.c"
error.error_exit(), line 71 in "error.c"
error.error(0x1, 0x0, 0x2934, 0x26f8, 0x1001b514, 0xd0b2,
0xe6009b00, 0x2ff3af50), line 212 in "error.c"
main.main_cleanup(sig = 6), line 389 in "main.c"
sighandle.SIG_handle(0x6), line 158 in "sighandle.c"
abort.abort() at 0xd017f294
assert.__assert(??, ??, ??) at 0xd02259fc

Mark Chojnacki
[EMAIL PROTECTED]
-


   
   
[EMAIL PROTECTED] (Larry Jones)
  
Sent by:To: [EMAIL 
PROTECTED] 
info-cvs-bounces+mchojnacki=symcor.ccc: [EMAIL 
PROTECTED]  
[EMAIL PROTECTED]  Subject: 
Re: pserver core dumps on WinCVS login   
   
   
   
   
02/26/03 05:57 PM  
   
   
   
   
   




[EMAIL PROTECTED] writes:
>
> OK. Here's what I get from dbx:
>
> $ dbx /usr/local/bin/cvs core
> Type 'help' for help.
> reading symbolic information ...
> [using memory image in core]
>
> Segmentation fault in expand_catname at 0xd01895b0 ($t1)
> 0xd01895b0 (expand_catname+0x18) 9421f780   stwu   r1,-2176(r1)
> (dbx)

That's nice, but it's not a traceback.  As I recall, the dbx command to
get a traceback is "where", but check the man page to be sure.

-Larry Jones

Sometimes I think the surest sign that intelligent life exists elsewhere
in the universe is that none of it has tried to contact us. -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs






___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

CVS on Solaris 2.8

2003-02-27 Thread Amit Sharma (SCM)

Hi,
I have installed CVS 1.11.5 on Solaris2.8 but getting a strange
problem while logging onto Server
cvs [login aborted]: recv() from server 10.91.208.12: EOF

Please help if anybody has faced the same problem and fixed

Regards,
Amit




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Restrict tag creation rights.

2003-02-27 Thread Ralf S. Engelschall

On Wed, Feb 26, 2003, Nitin Dube wrote:

> In CVS, is it possible to restrict the rights create a tag only to
> certain users?
> If it is possible, please guide me as to how can this be done?

It is possible through the $CVSROOT/CVSROOT/taginfo.
See the CVS manual for more details on how to use those hooks, please.

   Ralf S. Engelschall
   [EMAIL PROTECTED]
   www.engelschall.com

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: Lock contention executing cvs log

Re: Restrict tag creation rights.

RE: Restrict tag creation rights.

Lock contention executing cvs log

One of my CVS users is reporting conflicts on unchanged files afterrunning "cvs up -dP"....

Re: pserver core dumps on WinCVS login

Re: pserver core dumps on WinCVS login

Re: pserver core dumps on WinCVS login

Re: Info-cvs Digest, Vol 3, Issue 42

Re: Checkout problem on cvs host

Re: CVS on Solaris 2.8

Re: pserver core dumps on WinCVS login

CVS on Solaris 2.8

Re: Restrict tag creation rights.

14 matches

Site Navigation

Mail list logo

Footer information