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

Sun Jan 3 17:48:05 CET 2010

Can someone try with user threading to see if it is something in  
thread waiting?

Sent from my iPhone

On Jan 2, 2010, at 4:42 PM, Jay K <jay.krell at cornell.edu> wrote:

>  > 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 | Sit 
> z:
> > >>> 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
> > >