Subject: RE: wu-ftpd-2.4.2-beta-18-vr13 fails on AIX 4.2.1

From: "Steve D'Angona X4319" <[email-masked]>
Date: Tue, 16 Feb 1999 15:02:56 -0500 (EST)

I experienced the same problem using AIX V 4.3.2 and AIX C compiler
V4.4. Its peculiar because not all clients experienced the problem. We
have AIX and Sun boxes which did not have the problem. SGI's and FTP
Software's ftp clients did experience the problem...

I have tried the two offered workarounds. The first did not work with
IBM's C compiler. I put #undef THROUGHPUT in the main config.h and
src/config.h with the same results....

When I try a "get" from SGI boxes, and some other clients, I still get

451 local resource failure: malloc: Error 0.

Workaround # 2, using the gcc compiler V2.8.1, seems to work, although the
compiled code is quite a bit bigger than the AIX genn'd code. (But it
works:-)

Hope this helps...

Steve

In response to:
> 
> WORKAROUNDS:
> 
> Either of the following makes the ftpd work correctly:
> 
> 1. Use #undef THROUGHPUT in config.h.  This apparently makes
>    the compiler generate correct code.
> 
> 2. Compile with GCC:  In ./src go "make CC=gcc".
> 
> I have no further ideas on how to fool the AIX cc compiler into
> generating correct code.  You should talk to real AIX experts
> or submit the problem to IBM Support.
> 
> Our AIX C-compiler is xlC.C with the latest fixes at level 3.1.4.10.
> We do not have the new compiler version 4.4.
> 
> With best regards,
> 
> Ole Holm Nielsen
> Department of Physics, Building 307
> Technical University of Denmark, DK-2800 Lyngby, Denmark
> 
>

---

From: Dan Foster <[email-masked]>
Date: Tue, 16 Feb 1999 15:19:24 -0500 (EST)

Hot Diggety! On a bright and sunny day, Steve D'Angona X4319 was rumored to have said...
> 451 local resource failure: malloc: Error 0.

I think that's because you may have -D_AIX42 (for 4.2 and up) which
will select _LARGE_FILES, and *that* ends up picking the long long
value for off_t (look in system header file to find the #ifdef case).
(to support 64 bit file offsets, hence, not limited to +/- 2GB seeks)

One variable in there, blkcnt_size (if I recall?) is then typecasted
to an u_int, and I think endianness (AIX runs on big endian boxes AFAIK)
comes into play, reads 0 from some of the higher order memory locations that
an off_t takes up. And then when the code malloc(0), that fails...

Solution? Change (u_int) blkcnt_size to (off_t) blkcnt_size in
src/ftpd.c whereever you see it. I think it shows up in only one place?
off_t is supposed to be a more portable solution, I believe so it shouldn't
break even if an OS has 32bit support. (In AIX, if _LARGE_FILES is not
defined, then it will select a 'long' for off_t)

A 'proper' solution would probably involve creating a new #define in
the OS-specific config file for wu-ftpd (or one of its derivatives) and
allowing it to be set to an OS-specific typedef if set, else default to
u_int or something.

I also ran across several other 32/64 bit issues, mostly with %d, %ld, and
%lld printf templates - I'd have to dig up my patch. 64 bit-enabled code
should use %lld, 32 bit use %ld. Will print garbage if use wrong one,
sometimes compounded by architectural design (big/little endianness).

-Dan

---

From: Gregory A Lundberg <[email-masked]>
Date: Tue, 16 Feb 1999 15:33:11 -0500 (EST)

On Tue, 16 Feb 1999, Dan Foster wrote:

> to an u_int, and I think endianness (AIX runs on big endian boxes
> AFAIK) comes into play, reads 0 from some of the higher order memory
> locations that an off_t takes up. And then when the code malloc(0),
> that fails...
> 
> src/ftpd.c whereever you see it. I think it shows up in only one
> place? off_t is supposed to be a more portable solution, I believe so
> it shouldn't break even if an OS has 32bit support. (In AIX, if
> _LARGE_FILES is not defined, then it will select a 'long' for off_t)
> 
> the OS-specific config file for wu-ftpd (or one of its derivatives)
> and allowing it to be set to an OS-specific typedef if set, else
> default to u_int or something.
> 
> I also ran across several other 32/64 bit issues, mostly with %d, %ld,
> and %lld printf templates - I'd have to dig up my patch. 64
> bit-enabled code should use %lld, 32 bit use %ld. Will print garbage
> if use wrong one, sometimes compounded by architectural design
> (big/little endianness).
> 
> -Dan
> 

Patches are good, Greg likes patches.  Wouldn't happen to have some would
you?  Especially over the past week or so, with the growth in installed
base, I've got a lot of little things to fix up; patches make it go a lot
faster.  I'll take a look at the u_int/off_t thingy but I could swear I'd
already changed it to off_t and that didn't help.

I tried to fix a lot of the problems with garbage printing on wide
machines .. did I miss any?

-- 

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

---

From: Gregory A Lundberg <[email-masked]>
Date: Tue, 16 Feb 1999 15:58:14 -0500 (EST)

> > _LARGE_FILES is not defined, then it will select a 'long' for off_t)

I don't see this at all.  In fact, the only u_int I see is in a piece of
'well, duh!' code which I don't think is related to the problem at all.

Index: popen.c
===================================================================
RCS file: /cvsroot/wu-ftpd/src/popen.c,v
retrieving revision 1.1.1.1.2.6.2.2
diff -c -r1.1.1.1.2.6.2.2 popen.c
*** popen.c     1998/11/06 22:56:58     1.1.1.1.2.6.2.2
--- popen.c     1999/02/16 20:54:01
***************
*** 118,126 ****
          return (NULL);
  
      if (!pids) {
!         if ((pids = (int *) malloc((u_int) (fds * sizeof(int)))) == NULL)
                return (NULL);
-         (void) memset((void *)pids, 0, fds * sizeof(int));
      }
      if (pipe(pdes) < 0)
          return (NULL);
--- 118,126 ----
          return (NULL);
  
      if (!pids) {
!       pids = (int *) calloc (fds, sizeof (int));
!       if (pids == NULL)
                return (NULL);
      }
      if (pipe(pdes) < 0)
          return (NULL);

Yes, I know pids should be pid_t instead of int but I don't wanna go that
deep into it just yet.

--