[M3devel] Fwd: [CM3] #1080: CVSUPD server hangs if used with -C option
Tony Hosking
hosking at cs.purdue.edu
Sat Jan 2 20:35:59 CET 2010
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
>
More information about the M3devel
mailing list