Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/17/84; site think.ARPA Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!rose From: rose@think.ARPA (John Rose) Newsgroups: net.lang.c,net.lang.c++ Subject: Re: oops, corrupted memory again! Message-ID: <5097@think.ARPA> Date: Mon, 5-May-86 10:52:47 EDT Article-I.D.: think.5097 Posted: Mon May 5 10:52:47 1986 Date-Received: Tue, 6-May-86 06:53:42 EDT References: <4495@cbrma.UUCP> <763@bentley.UUCP> Reply-To: rose@think.UUCP (John Rose) Organization: Thinking Machines, Cambridge, MA Lines: 55 Xref: watmath net.lang.c:8872 net.lang.c++:194 In article <763@bentley.UUCP> kwh@bentley.UUCP (KW Heuer) writes: >In article <4495@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@think.arpa ihnp4!think!rose