[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