Path: utzoo!mnetor!uunet!husc6!uwvax!umn-d-ub!umn-cs!ems!pwcs!elric!root
From: root@elric.UUCP (root)
Newsgroups: comp.unix.microport
Subject: Re: Info needed: UNIX for 286/386 machines (really malloc)
Message-ID: <412@elric.UUCP>
Date: 3 Mar 88 20:08:25 GMT
References: <4213@sigi.Colorado.EDU> <863@athos.rutgers.edu> <141@bdt.UUCP>
Organization: Unisys Inc., Eagan,MN
Lines: 21
Summary: could be -lmalloc

In article <141@bdt.UUCP>, david@bdt.UUCP (David Beckemeyer) writes:
> In article <863@athos.rutgers.edu> hedrick@athos.rutgers.edu (Charles Hedrick) writes:
> >[..] later found out that this was because the supplied malloc is
> >substandard.  I'm now using a tuned malloc, and I think Emacs would [..]
> 
> What is the "tuned malloc" that Charles is talking about?  Is it something
> from Microport?  Does it exist for the 286 version too?

Perhaps the "tuned malloc" that Charles is talking about is the malloc library
that can be loaded with a -lmalloc on the cc command line.  I have done most of
my development work on a vax 11/780 running "real" att sysVr2.0 and have
occasionally run into mysterious (and dreaded) core dump problems using the
"standard" malloc but find that they go away when i use -lmalloc; without
changing any code -- simply recompiling!

So, what I do is, unless i have a special reason to use the other features of
the -lmalloc (a faster malloc, according to the man page) i just use the
standard malloc until i get dumb core dumps, then i try the -lmalloc to see if
the problem goes away.  Most of the time, it does....
-- 
Derek Terveer	root@elric.UUCP		..!clyde!lily!elric!root