[M3devel] Fwd: [CM3] #1080: CVSUPD server hangs if used with -C option
Olaf Wagner
wagner at elegosoft.com
Sat Jan 2 11:54:06 CET 2010
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, Germany
>> 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, Germany
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
More information about the M3devel
mailing list