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