oops, corrupted memory again!

[John Rose]

In article <763 at bentley.UUCP> kwh at bentley.UUCP (KW Heuer) writes:
>In article <4495 at cbrma.UUCP> cbrma!trl (Tom Lanning) writes:
>>	Are there any "malloc" routines that check for modification of
>>malloc's link pointers by the "user's" code?   Close to 70% of by bugs
>>are stack/memory problems were I use more space than I allocated.
>
>As mentioned in the man page, the malloc() code has a compile-time option
>for strict checks on the arena.  (This is not too useful if you have no
>source code, of course.)
If you do have source code, here's another suggestion which has worked
very well for me.  Define an circular buffer which stores a record of
the last few hundred records of malloc/free/morecore history.  Make
sure your symbolic debugger can dump it for you.  This trick alone
has saved me hours of debugging time on quite a few occasions.
In my applications, someone would either (1) try to use freed storage,
or (2) go off the end of allocated storage, and usually these errors
occurred within a dozen history events after the call to (1) free or
(2) malloc.

>Now, if only somebody would invent an architecture where all objects,
>including dynamicly allocated objects, are isolated in memory, then any
>subscript error would cause an immediate memory fault.  You'd still be
>vulnerable to completely wild pointers (but less likely in a huge address
>space), and overflow of an array inside a structure might be untrappable,
>but otherwise it sounds like a great machine to do your debugging on.
>
>Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint

It's called the "Lisp Machine".  All storage is allocated and manipulated
according to very strict typing rules, enforced in microcode.  If you walk
off the end of an array, you get an immediate break into the debugger,
with options to (a) abort, (b) re-invoke any stack frame, (c) return from
any stack frame, (d) extend the array in place, (e) anything else you
can specify in Lisp (the debugger, command loop, and application all
run in the same address space!  This is safe because of the enforcement
mentioned above).  The C compiler I'm using (Zeta-C from Zeta-Soft, Ltd.)
implements pointers (approximately) as ordered pairs of arrays and indexes.

The bounds-checking can be done in macrocode on a conventional machine.
The BCC compiler (from Delft Consulting?) does this by source-transforming
a C program so that pointers turn into small records carrying bounds
information.

Both systems (as far as I know) model the C runtime memory as a collection
of "floating" byte arrays.  Part of the justification for this is found in K&R
RefMan 7.6 "Pointer comparison is portable only when the pointers point to
objects in the same array."

[Disclaimer:  I have no professional connection with the Zeta-C or BCC
companies, although I do know the implementors of both products personally.]
-- 
----------------------------------------------------------
John R. Rose		     Thinking Machines Corporation
245 First St., Cambridge, MA  02142    (617) 876-1111 X270
rose at think.arpa				  ihnp4!think!rose