Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!rpi!usc!apple!agate!dog.ee.lbl.gov!nosc!crash!nusdecs!rwhite
From: rwhite@nusdecs.uucp (Robert White)
Newsgroups: comp.unix.sysv386
Subject: Re: malloc() problems
Keywords: malloc, ISC, Esix
Message-ID: <1991Apr7.221646.22223@nusdecs.uucp>
Date: 7 Apr 91 22:16:46 GMT
References: <1991Apr05.211827.23819@dialogic.com>
Organization: National University, San Diego
Lines: 38

Reguarding core dump durring malloc.

This has happened to me, but times that it happened I found the program
to be at fault and not malloc.  (This has happened to me under AT&T
SVR3 on the 3B and 386 implementations)  If you mis-use a chunk of malloced
memory (e.g. write sizeof()+n bytes to the porinter address instead of
limiting writes to sizeof(), or mangle/munge pointer derefrencing before
a write) you can damage the allocation pool structures maintained by the
malloc library.  The next time (or then Nth time) you malloc after that
the structure-traversal-to-find-a-sufficent-size-hole-in-the-pool part
of the allocation can go springing off into places it should not be.
Reading those places are fine (isn't virtual memory wounderful) but
when it traverses the garbage and "finds" the aparence of a whole it
trys to modify the placement structures to allocate the memory.  One
of two things result:

	1)  If the region is within the legally writeable space of the
	process image you get damaged data.  A condition that can be very
	hard to detect as it can take the form of bad function return
	addresses.

	2)  If the region is within a protection area (your code region,
	a shared library map into you process space, the system call entry
	area, constant data space [and/or however those sort of things
	are implemented in your implementation]) you will get a memory
	protection fault (and hence an immediate core dump) durring the
	allocation call.

In short, before you go trying to reverse-engineer your malloc(3) library
you should review the pointer usages in all your source and home-grown
libraries.  Functions most likley to blame are things like strcat, getstr, 
and the like.  Anyplace you pass a pointer to an aray that will be written on
without the size of the aray you should be suspicious.
-- 
Robert C. White Jr.    |  The degree to which a language may be
Network Administrator  |   classified as a "living" language
National University    |  is best expressed as the basic ratio
crash!nusdecs!rwhite   |   of its speakers to its linguists.