Hi, I am trying to mirror ftp://patches.sun.com/patchroot/all_unsigned with lftp under Solaris. What happens is that lftp runs into the situation where its process quickly eats up all available virtual memory and then aborts.
My lftp runs on SUNs (SPARC 10/20, Ultra 5/10, EP3500, i.e. no matter what SPARC hardware with up to 4 GB physical memory). lftp is compiled from source (3.0.11/12/13) with either gcc 3.3.2 or Solaris WorkShop 5u2 cc. I have played around somewhat with options in lftp.conf - no matter, in all cases I run into the situation described above. In more detail: With debug on I get the following: copy: get hit eof copy: waiting for put confirmation copy: put confirmed store copy: get is finished - all done dns cache hit ---- Connecting to patches.sun.com (192.18.108.60) port 21 <--- 220 scfe280r2 FTP server (Version wu-2.6.2(3) Mon Oct 4 22:38:13 PDT 2004) ready. ---> FEAT <--- 530 Please login with USER and PASS. ---> USER anonymous <--- 230 .............. ---> CWD /all_unsigned <--- 250 CWD command successful. ---> PASV <--- 227 Entering Passive Mode (192,18,108,60,78,251) ---- Connecting data socket to (192.18.108.60) port 20219 ---> LIST <--- 150 Opening ASCII mode data connection for /bin/ls. ---- Got EOF on data connection ---- Closing data socket <--- 226 Transfer complete. The directory content listing seems to be transferred completely. The packet log tells me TCP out 192.18.108.60:21 in 132.180.15.13:38133 idle 0:00:00 Bytes 1732 flags UI O TCP out 192.18.108.60:20219 in 132.180.15.13:38135 idle 0:00:00 Bytes 3026988 fl ags UIP ........... (after "Got EOF on data connection":) TCP out 192.18.108.60:21 in 132.180.15.13:38133 idle 0:00:00 Bytes 1756 flags UI O Now tracing syscalls with truss tells me: read(7, 0x00107C10, 65536) Err#11 EAGAIN read(7, 0x00107C10, 65536) Err#11 EAGAIN poll(0x000EC9F0, 1, 788) = 1 read(7, " 2 2 6 T r a n s f e r".., 65536) = 24 read(7, 0x00107C10, 65536) Err#11 EAGAIN write(4, " < - - - 2 2 6 T r a".., 28) = 28 read(7, 0x00107C10, 65536) Err#11 EAGAIN read(7, 0x00107C10, 65536) Err#11 EAGAIN read(7, 0x00107C10, 65536) Err#11 EAGAIN read(7, 0x00107C10, 65536) Err#11 EAGAIN brk(0x00526238) = 0 brk(0x00528238) = 0 brk(0x00528238) = 0 brk(0x0052A238) = 0 brk(0x0052A238) = 0 brk(0x0052C238) = 0 brk(0x0052C238) = 0 brk(0x0052E238) = 0 brk(0x0052E238) = 0 brk(0x00530238) = 0 brk(0x00530238) = 0 brk(0x00532238) = 0 ................. (millions of times until virtual mem exhausted) brk() is used by malloc() for expanding the heap, and thats exactly what can be observed. Tracing with ddd/gdb shows xmalloc activity, the Backtrace shows: #7 0x3da34 in main () at lftp.cc:404 #6 0x3d1d8 in _Z8WaitDoneP7CmdExec () at lftp.cc:73 #5 0x6b6f8 in _Z6SMTask8ScheduleEv () at SMTask.cc:168 #4 0xe4b8c in _ZN20GenericParseListInfo2DoEv () at NetAccess.cc:748 #3 0xb7a14 in _ZN11FtpListInfo5ParseEPKci () at FtpListInfo.cc:48 #2 0xb7dc4 in _ZN3Ftp13ParseLongListEPKciPi () at FtpListInfo.cc:119 #1 0x834dc in _ZN7FileSet3AddEP8FileInfo () at FileSet.cc:112 #0 _Z8xreallocPvj () at xmalloc.cc:75 Has anybody observed something similar? Can anybody confirm that behaviour of lftp in connection with mirroring at least parts of patches.sun.com? Thanks in advance Martin Bahr
