[M3devel] Fwd: [CM3] #1080: CVSUPD server hangs if used with -C option
Olaf Wagner
wagner at elegosoft.com
Tue Dec 29 18:47:48 CET 2009
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
More information about the M3devel
mailing list