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
