malloc() problems
Robert White
rwhite at nusdecs.uucp
Mon Apr 8 08:16:46 AEST 1991
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.
More information about the Comp.unix.sysv386
mailing list