Subject: get problem

From: Mark Francis <[email-masked]>
Date: Fri, 8 Jan 1999 11:58:53 -0000

Hello everyone, I've just loaded wu-ftpd-2.4.2-beta-18, it appears to 
be working fine, but every now and again when
I try and use get to download data from the host, I get the following 
message :
451 local resource failure: malloc : No such file or directory
Can anyone help ?
Cheers,
Mark Francis
Teamwork Solutions Limited
Sunley Tower, Piccadilly Plaza
Manchester M1 4BT, United Kingdom

Tel:	+44(0) 161 228 2286
Fax:	+44(0) 161 228 2900

mailto: [email-masked]
web: http://www.teamwork-solutions.com

---

From: Gregory A Lundberg <[email-masked]>
Date: Fri, 8 Jan 1999 10:41:57 -0500 (EST)

On Fri, 8 Jan 1999, Mark Francis wrote:

> be working fine, but every now and again when I try and use get to
> download data from the host, I get the following message :
> 

This message occurs in ftpd.c when trying to allocate memory for a file
buffer.  In both send_data() and receive_data, this occurs with TYPE I and
TYPE L transfers only.

One point: the message in the daemon uses "Local resource failure: malloc"
(notice the capital 'L').  This discrepancy could be due to hand-typing
the message, or it could indicate you're not running the version of the
daemon you believe you are.

In receive_data(), the function call reads as:

	if ((buf = (char *) malloc(BUFSIZ)) == NULL) {

I cannot find any definition of BUFSIZ anywhere in the source kit, so this
could be the cause of the problem (unless the runtime is supposed to
define it).  If BUFSIZ is undefined, it will probably be assumed to be
zero.  I should hope that attempting to malloc(0) will result in a runtime
error.

In send_data(), the function call reads as:

	if ((buf = (char *) malloc((u_int) blksize)) == NULL) {

where blksize is passed into the function.  The call to send_data reads:

	#ifdef HAVE_ST_BLKSIZE
	    send_data(fin, dout, st.st_blksize*2);
	#else
	    send_data(fin, dout, BUFSIZ);
	#endif

HAVE_ST_BLKSIZE is set in the local configurations.  grep reveals:

config.aix:#define HAVE_ST_BLKSIZE
config.aux:#define HAVE_ST_BLKSIZE
config.bdi:#define HAVE_ST_BLKSIZE
config.bsd:#define HAVE_ST_BLKSIZE
config.dec:#define HAVE_ST_BLKSIZE
config.dgx:#define HAVE_ST_BLKSIZE
config.dyn:#define HAVE_ST_BLKSIZE
config.fbs:#define HAVE_ST_BLKSIZE
config.gen:#define HAVE_ST_BLKSIZE
config.hiu:#define HAVE_ST_BLKSIZE
config.hpx:#define HAVE_ST_BLKSIZE
config.lnx:#define HAVE_ST_BLKSIZE
config.nbs:#define HAVE_ST_BLKSIZE
config.nx2:#define HAVE_ST_BLKSIZE
config.nx3:#define HAVE_ST_BLKSIZE
config.osf:#define HAVE_ST_BLKSIZE
config.ptx:#undef  HAVE_ST_BLKSIZE
config.s41:#define HAVE_ST_BLKSIZE
config.sco:#define HAVE_ST_BLKSIZE
config.sco:#undef  HAVE_ST_BLKSIZE
config.sgi:#undef  HAVE_ST_BLKSIZE
config.sny:#define HAVE_ST_BLKSIZE
config.sol:#define HAVE_ST_BLKSIZE
config.ult:#define HAVE_ST_BLKSIZE
config.uxw:#define HAVE_ST_BLKSIZE

BUFSIZ is used many places in the source code, grep reveals:

extensions.c:    char buf[BUFSIZ];
extensions.c:  char cwdir[BUFSIZ];
extensions.c:  char path[BUFSIZ];
extensions.c:  char cwdir[BUFSIZ];
extensions.c:  char path[BUFSIZ];
ftpcmd.y:           char line[BUFSIZ], *ptr = line;
ftpd.c:char proctitle[BUFSIZ];         /* initial part of title */
ftpd.c:    char line[BUFSIZ];
ftpd.c:        static char line[BUFSIZ];
ftpd.c:        st.st_blksize = BUFSIZ;
ftpd.c:    send_data(fin, dout, BUFSIZ);
ftpd.c:        if ((buf = (char *) malloc(BUFSIZ)) == NULL) {
ftpd.c:        while ((cnt = read(netfd, buf, BUFSIZ)) > 0 &&
ftpd.c:    char line[BUFSIZ], *ptr;
ftpd.c:  char buf[BUFSIZ];
ftpshut.c:    char buf[BUFSIZ];
glob.c: char agpath[BUFSIZ];
glob.c: char restbuf[BUFSIZ + 2];

All in all, I must say that this handling of BUFSIZ makes me very nervous.
On my Linux system BUFSIZ is defined in <stdio.h> as 1024, but ISTM that
BUFSIZ is *not* part of the ANSI/ISO C specification so it shouldn't be
depended upon.  If it _is_ part of the standard then there's no problem ..
unfortunately my printed copy of the standard isn't with me so I'll have
to check later.

Let's assume the code is correct and the error is a true runtime problem.
Check the resource limits the daemon is running under.  Is it possible the
rlimits are too low?  Is it possible the machine is doing so much you're
really running out of memory?

You say 'sometimes' .. given that this error can only occur on TYPE I and
TYPE L transfers (that's 'binary' mode for most clients) can you
consistently cause it to occur?

-- 

Gregory A Lundberg		Senior Partner, VRnet Company
1441 Elmdale Drive              [email-masked]
Kettering, OH 45409-1615 USA    1-800-809-2195