Malloc problems

[Every system needs one]

In article <272 at marob.MASA.COM>, daveh at marob.MASA.COM (Dave Hammond) writes:
> Problem: on subsequent passes (free old, read data, allocate new space)
> malloc() core dumps. Traces show that the structure addresses have not
> moved since the first pass (i.e. no pointer address screwups) and the
> problem does not appear in smaller versions of the application (its currently
> running on an Intel 286 machine under SCO Xenix, as a Large model
> program - about 100K binary file size).
> 
> As a remedy I've written a set of routines which allocate large chunks
> of memory on startup and then parcel out portions as necessary. This
> seems to work, but should I have to do this?
> 
> Is the problem with a)Xenix, b)the malloc() package, c) ??

The Library routines malloc() and free() are broken under SCO Xenix 2.2.0
through 2.2.2 (controlled release).  This has been reported, but I have
no idea if/when it will be fixed, as the compiler and libraries belong to
MicroSoft, and there is a rather long backward chain to get problems gone.

My guess is that MicroSoft has already fixed it in the next release --
which hasn't been released yet.  I have no idea of the propagation time
between a MicroSoft fix and an SCO release, either.  I'll ask around.

Any fix, of course, will probably leave Tandy Xenix, which is an OEM'ed
version of MicroSoft, out in the cold, as they [Tandy] are always several
revisions out of date.

-=< THE FIX >=- (trumpet music or strumpet music, whichever)

Your fix is one of the two best available.  The other is to use an Altos
developement system and libraries from a 686, 886, or 1086.  This has the
added advantage that your programs will run on all 80286 based Altos boxes
(with the exception of the 2086, which is DIFFERENT), all of the SCO Xenix
systems (Although serial I/O is somewhat screwed on modem devices under 2.1.3)
and even L/F technologies systems (Although a MicroPort UNIX version runs
better there, L/F boxes WILL load Xenix binaries).  As a bonus, optimization
is somewhat better (a 486/586/986 8086 Altos Xenix compiler compiles our
product small enough that it will run on the XT version of SCO Xenix; the
SCO compiler produces the message "program too large") and can save you if
you're just on the boarder.

Warning:  SCO 2.2.2 (Xenix 386) has the same malloc problem with Altos
generated code, so don't necessarily run out and buy an Altos developement
system... your fix is best, in this case.  For more implementations, see the
C programming Bible (K&R), wherin malloc() and free() are implemented for
you.


| Terry Lambert           UUCP: ...{ decvax, ihnp4 } ...utah-cs!century!terry |
| @ Century Software        OR: ...utah-cs!uplherc!sp7040!obie!wsccs!terry    |
| SLC, Utah                                                                   |
|                   These opinions are not my companies, but if you find them |
|                   useful, send a $20.00 donation to Brisbane Australia...   |
| 'Admit it!  You're just harrasing me because of the quote in my signature!' |