[M3devel] Fwd: [CM3] #1080: CVSUPD server hangs if used with -C option

Jay K jay.krell at cornell.edu
Sat Jan 2 22:42:22 CET 2010


 > It must have been working relatively recently.

This is probably the first time it has been tested since getting into our tree.

 - Jay

> From: hosking at cs.purdue.edu
> To: wagner at elegosoft.com
> Date: Sat, 2 Jan 2010 13:35:59 -0600
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Fwd: [CM3] #1080: CVSUPD server hangs if used with -C	option
> 
> So, what's changed recently to break this?  It must have been working  
> relatively recently.
> 
> Sent from my iPhone
> 
> On Jan 2, 2010, at 4:54 AM, Olaf Wagner <wagner at elegosoft.com> wrote:
> 
> > Quoting Tony Hosking <hosking at cs.purdue.edu>:
> >
> >> What does -C do?
> >
> > Make it a server process. From the manual:
> >
> >     -C maxClients
> >                 Limits the number of simultaneous clients to  
> > maxClients.
> >                 Clients beyond the specified maximum are politely  
> > refused
> >                 service.
> >
> >                 If this option is not specified, cvsupd serves one  
> > client in
> >                 the foreground and then exits.
> >
> > Olaf
> >
> >> On 29 Dec 2009, at 12:47, Olaf Wagner wrote:
> >>
> >>> Any ideas? Interaction problem between threads and select?
> >>>
> >>> Olaf
> >>>
> >>> ----- Forwarded message from bugs at elego.de -----
> >>>   Date: Tue, 29 Dec 2009 16:23:23 -0000
> >>>   From: CM3 <bugs at elego.de>
> >>> Reply-To: CM3 <bugs at elego.de>
> >>> Subject: [CM3] #1080: CVSUPD server hangs if used with -C option
> >>>     To: @MISSING_DOMAIN
> >>>
> >>> #1080: CVSUPD server hangs if used with -C option
> >>> ----------------------------- 
> >>> +----------------------------------------------
> >>> Reporter:  rajeshvadivelu  |            Owner:  wagner
> >>>     Type:  sw-bug          |           Status:  new
> >>> Priority:  high            |        Milestone:
> >>> Component:  sys             |          Version:  5.8-RC3
> >>> Severity:  critical        |         Keywords:
> >>>  Relnote:                  |     Confidential:  no
> >>>      Org:  Collabnet       |   Estimatedhours:  0
> >>>    Hours:  0               |         Billable:  0
> >>> Totalhours:  0               |
> >>> ----------------------------- 
> >>> +----------------------------------------------
> >>> Htr:
> >>> Install cvsup from cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz  
> >>> package.
> >>>
> >>> Start the cvsupd server with -C option
> >>>
> >>> ./cvsupd -b /data/cvsupd -C 2
> >>>
> >>> Try cvsup client to connect to the sever
> >>>
> >>> ./cvsup -g -L 2 /tmp/cvsupd.cfg
> >>>
> >>> The client connection will hang and after sometime we will get   
> >>> "Inactivity timeout"
> >>>
> >>>
> >>> Fix:
> >>>
> >>>
> >>>
> >>> Env:
> >>>
> >>>
> >>> ----------------------------- 
> >>> +----------------------------------------------
> >>> In a RHEL5 32bit box I was trying to run cvsupd server to mirror  
> >>> my cvs
> >>> repo. I did used cm3-bin-ws-cvsup-LINUXLIBC6-5.8.4-RC4.tgz to get  
> >>> the
> >>> cvsup installed.
> >>>
> >>> The server starts find and there was no issues if I start the server
> >>> without -C option.
> >>>
> >>> Starting cvsupd server without -C option
> >>>
> >>> $ ./cvsupd -b /u2/site/data/cvsupd
> >>> 2009.12.29 21:31:05 IST [6225]: CVSup server started
> >>> 2009.12.29 21:31:05 IST [6225]: Software version: 2009-08-30  
> >>> 21:02:46
> >>> 2009.12.29 21:31:05 IST [6225]: Protocol version: 17.0
> >>> 2009.12.29 21:31:05 IST [6225]: Ready to service requests
> >>>
> >>> Then I did a client request as below
> >>>
> >>> $ ./cvsup -g -L 2 /tmp/cvsupd.cfg
> >>> Parsing supfile "/tmp/cvsupd.cfg"
> >>> Connecting to myserver.com
> >>> Connected to myserver.com
> >>> Rejected by server: Access denied
> >>> Will retry at 21:37:09
> >>>
> >>> So the request was successful and I get a valid error message at the
> >>> client.
> >>>
> >>> But when I start the server with -C option like the one as below,  
> >>> requests
> >>> from client are hanging and eventually getting "Inactivity  
> >>> timeout" after
> >>> sometime.
> >>>
> >>> $ ./cvsupd -b /u2/site/data/cvsupd -C 2
> >>>
> >>> When ever a new client connection was made, this daemon clones  
> >>> another
> >>> cvsupd process and it also hangs. So none of the client request were
> >>> processed.
> >>>
> >>> Strace of the main cvsupd server process, when a new client  
> >>> request was
> >>> fired.
> >>>
> >>> -----------------------------------
> >>> select(4, [3], [], [3], {0, 39000})     = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 1 (in [3], left {0,  
> >>> 553000})
> >>> accept(3, {sa_family=AF_INET, sin_port=htons(51221),
> >>> sin_addr=inet_addr("208.75.198.60")}, [16]) = 6
> >>> setsockopt(6, SOL_SOCKET, SO_LINGER, {onoff=1, linger=1}, 8) = 0
> >>> setsockopt(6, SOL_TCP, TCP_NODELAY, [1], 4) = 0
> >>> fcntl64(6, F_GETFL)                     = 0x2 (flags O_RDWR)
> >>> fcntl64(6, F_SETFL, O_RDWR|O_NONBLOCK)  = 0
> >>> gettimeofday({1262103026, 146476}, NULL) = 0
> >>> open("/u2/site/data/cvsupd/cvsupd.access", O_RDONLY|O_LARGEFILE) = 7
> >>> fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0
> >>> _llseek(7, 0, [0], SEEK_CUR)            = 0
> >>> fstat64(7, {st_mode=S_IFREG|0755, st_size=215, ...}) = 0
> >>> close(7)                                = 0
> >>> gettimeofday({1262103026, 147481}, NULL) = 0
> >>> stat64("/u2/site/data/cvsupd/cvsupd.class", 0xbf809c04) = -1  
> >>> ENOENT (No
> >>> such file or directory)
> >>> write(5, "\0", 1)                       = 1
> >>> futex(0x91580f0, FUTEX_WAKE, 1)         = 1
> >>> futex(0x9158098, FUTEX_WAKE, 1)         = 1
> >>> futex(0x91580b8, FUTEX_WAKE, 1)         = 1
> >>> futex(0x91580bc, FUTEX_WAIT, 5, NULL)   = -1 EAGAIN (Resource  
> >>> temporarily
> >>> unavailable)
> >>> futex(0x9158098, FUTEX_WAKE, 1)         = 0
> >>> clone(child_stack=0,
> >>> flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
> >>> child_tidptr=0xb7f43708) = 6543
> >>> futex(0x915a484, 0x5 /* FUTEX_??? */, 1) = 1
> >>> futex(0x915a460, FUTEX_WAKE, 1)         = 1
> >>> futex(0x91580f0, FUTEX_WAKE, 1)         = 1
> >>> futex(0x9158098, FUTEX_WAKE, 1)         = 1
> >>> futex(0x91580b8, FUTEX_WAKE, 1)         = 1
> >>> futex(0x91580bc, FUTEX_WAIT, 7, NULL)   = -1 EAGAIN (Resource  
> >>> temporarily
> >>> unavailable)
> >>> futex(0x9158098, FUTEX_WAKE, 1)         = 0
> >>> close(6)                                = 0
> >>> accept(3, 0xbf809e44, [16])             = -1 EAGAIN (Resource  
> >>> temporarily
> >>> unavailable)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>> select(4, [3], [], [3], {1, 0})         = 0 (Timeout)
> >>>
> >>> ------------------------------------
> >>>
> >>> gdb backtrace of the main cvsupd server process
> >>>
> >>> ------------------------------------
> >>>
> >>> #0  0x00a2a402 in __kernel_vsyscall ()
> >>> #1  0x0026efb1 in ___newselect_nocancel () from /lib/libc.so.6
> >>> #2  0x00f8965b in Unix__select (nfds=4, readfds=0xb7f9df78,
> >>> writefds=0xb7f9df88, exceptfds=0xb7f9df98, timeout=0xbfed9410) at
> >>> ../src/unix/Common/UnixC.c:301
> >>> #3  0x00f85f4b in ThreadPThread__XIOWait__CallSelect.779  
> >>> (M3_Cwb5VA_nfd=4,
> >>> M3_A4bqCj_timeout=0xbfed9410) at
> >>> ../src/thread/PTHREAD/ThreadPThread.m3:900
> >>> #4  0x00f85c7a in ThreadPThread__XIOWait (M3_BXP32l_self=0xb7f9400c,
> >>> M3_Cwb5VA_fd=3, M3_AicXUJ_read=1 '\001',
> >>> M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1  
> >>> '\001')
> >>>    at ../src/thread/PTHREAD/ThreadPThread.m3:936
> >>> #5  0x00f8589d in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=3,
> >>> M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at
> >>> ../src/thread/PTHREAD/ThreadPThread.m3:854
> >>> #6  0x00e4b499 in TCPMisc__AcceptFrom (M3_AahksS_c=0xb7f9ca48,
> >>> M3_DoBjMZ_peer=0xbfed9970) at ../src/POSIX/TCP.m3:458
> >>> #7  0x0807bcbf in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at
> >>> ../src/FSServer.m3:153
> >>> #8  0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:336
> >>> #9  0x00f717c8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a11a0) at
> >>> ../src/runtime/common/RTLinker.m3:399
> >>> #10 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at
> >>> ../src/runtime/common/RTLinker.m3:113
> >>> #11 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at
> >>> ../src/runtime/common/RTLinker.m3:122
> >>> #12 0x0804db1e in main (argc=5, argv=0xbfeda124, envp=0xbfeda13c) at
> >>> _m3main.mc:4
> >>> ------------------------------------------------
> >>>
> >>>
> >>> strace of the cloned cvsupd process
> >>>
> >>> -----------------------------------
> >>>
> >>> futex(0x91580bc, FUTEX_WAIT, 3, NULL
> >>>
> >>> -----------------------------------
> >>>
> >>> gdb backtrace of the cloned cvsupd process
> >>>
> >>> -----------------------------------
> >>>
> >>> #0  0x00a2a402 in __kernel_vsyscall ()
> >>> #1  0x00320146 in pthread_cond_wait@@GLIBC_2.3.2 () from
> >>> /lib/libpthread.so.0
> >>> #2  0x00f886e6 in ThreadPThread__pthread_cond_wait (cond=0x89c60b8,
> >>> mutex=0x89c6098) at ../src/thread/PTHREAD/ThreadPThreadC.c:326
> >>> #3  0x00f81d9d in ThreadPThread__XWait (M3_BXP32l_self=0xb7f9400c,
> >>> M3_AYIbX3_m=0xb7f9c8d8, M3_Bl0jv4_c=0xb7f9c8f4,  
> >>> M3_AicXUJ_alertable=0
> >>> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:238
> >>> #4  0x00f821ae in Thread__Wait (M3_AYIbX3_m=0xb7f9c8d8,
> >>> M3_Bl0jv4_c=0xb7f9c8f4) at ../src/thread/PTHREAD/ 
> >>> ThreadPThread.m3:280
> >>> #5  0x00bd4e14 in SigHandler__ChangeState (M3_BnMAgS_d=0xb7f9c4bc,
> >>> M3_AkN0P6_state=2 '\002') at ../src/SigHandler.m3:105
> >>> #6  0x00bd5ba6 in SigHandler__ShutDown () at ../src/ 
> >>> SigHandler.m3:243
> >>> #7  0x0807cbac in FSServer_M3_LINE_230.718 (L_2=0xbfed95d0) at
> >>> ../src/FSServer.m3:231
> >>> #8  0x0807c956 in FSServer__Run (M3_DS26rk_self=0xb7f9c9fc) at
> >>> ../src/FSServer.m3:227
> >>> #9  0x080934fd in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:336
> >>> #10 0x00f717c8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a11a0) at
> >>> ../src/runtime/common/RTLinker.m3:399
> >>> #11 0x00f70b82 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a11a0) at
> >>> ../src/runtime/common/RTLinker.m3:113
> >>> #12 0x00f70c10 in RTLinker__AddUnit (M3_DjPxE5_b=0x8090f4e) at
> >>> ../src/runtime/common/RTLinker.m3:122
> >>> #13 0x0804db1e in main (argc=5, argv=0xbfeda124, envp=0xbfeda13c) at
> >>> _m3main.mc:4
> >>>
> >>> -------------------------------------------
> >>>
> >>> So it looks like both the main and cloned cvsupd processes were  
> >>> waiting
> >>> for a response from the kernel call "__kernel_vsyscall ()". Under  
> >>> what
> >>> condition will this happen? Am I doing something wrong here?
> >>>
> >>> --
> >>> Ticket URL: <http://projects.elego.de/cm3/ticket/1080>
> >>> CM3 <http://projects.elego.de/cm3>
> >>> Critical Mass Modula3 Compiler
> >>>
> >>>
> >>> ----- End forwarded message -----
> >>>
> >>>
> >>> --
> >>> Olaf Wagner -- elego Software Solutions GmbH
> >>>              Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, G 
> >>> ermany
> >>> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
> >>>  http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: 
> >>>  Berlin
> >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:  
> >>> DE163214194
> >>>
> >>
> >>
> >
> >
> >
> > -- 
> > Olaf Wagner -- elego Software Solutions GmbH
> >               Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germ 
> > any
> > phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
> >   http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Be 
> > rlin
> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:  
> > DE163214194
> >
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100102/c756c57e/attachment-0002.html>


More information about the M3devel mailing list