From: bergman@panix.com (Mark Bergman)
Newsgroups: comp.os.msdos.programmer,comp.lang.c,alt.msdos.programmer
Subject: C Memory Debuggers (SUMMARY)
Date: 4 Jan 93 00:50:39 GMT
Organization: Panix Public Access Internet & Unix, NYC

Sorry for the long delay, but here is a summary of responses
I got from my request for information on DOS C source memory
debuggers. Any additions are welcome, and all E-mail will
get a response.

Many thanks to those who responded:

	FFAAC01%BLEKUL11.BITNET@pucc.Princeton.EDU
	John.Larson@f824.n107.z1.ieee.org (John Larson)
	Levin F Magruder <cmcl2!world.std.com!levin>
	Rick Huff <cmcl2!billnext.tamu.edu!rick>
	bryan@stiatl.salestech.com (Bryan Donaldson)
	chris.lincoln%travel@wugate.wustl.edu (Chris Lincoln)
	draper@ais.org (Patrick Draper)
	freeman@gradient.cis.upenn.edu (Jon Freeman)
	gap@TRICERATOPS.SOAR.CS.CMU.EDU
	ilic@utkux1.utk.edu
	janos%novdpd@novell.com (Janos Haide)
	mikey@ontek.com (euphausia superba)
	schunix!sonix@transfer.stratus.com (Duane Morin)
	scs@adam.mit.edu (Steve Summit)
	smclewin@ultrix.ramapo.edu (Scott M McLewin)


==> Date: Tue, 8 Sep 92 12:06 EDT
==> From: cmcl2!transfer.stratus.com!schunix!sonix (Duane Morin)
==> Organization: SCHUNIX Public Access Unix for Worcester County, Massachusetts, USA
==> 
==> 
==> Memcheck is an actual C library that you #include and link in to the code
==> that you want to check.  It's THIS program that defaults to only measuring 
==> alloc'd memory, expecting you to explicitly mention arrays and things of 
==> that sort.  Again, I had little luck with this one because, since it does
==> run within your program (as compared to a BC or a SoftIce), using it means
==> changing the addresses within your program, therefore possibly negating 
==> statements that were causing errors.  Many times, I'd have a NULL pointer 
==> running around that would cause my program to crash.  I'd link in memcheck,
==> only to discover that the shifting around of memory had caused the error to 
==> show up in a different place, or perhaps not at all.
==> 
==> BoundsChecker - Disappointing.
==> BoundsChecker runs on top of your program and checks for places where,
==> of course, bounds have been overwritten.  Examples of this would include:
==> executing code out of your program space (i.e. jumping into your data segment),
==> writing into your code space, or trying to access normally unreadable 
==> memory (such as Video memory, or certain BIOS variables or interrupt tables).  
==> My problem with it is that, as they say in a little addition to the manual,
==> certain compilers (such as Borland C++) DO overwrite code segments or call
==> supposedly bad memory areas, and are perfectly legitimate in doing so.  Thus,
==> when boundschecker pops up with a screen full of assembly language pointing
==> to a " rep movsb "  at location 0Af3:0002, you are expected to determine 
==> whether or not this is your fault, or the compiler just doing something that's
==> perfectly legal.  Basically, I spent most of my time using it by telling it
==> to "ignore" every bounds error that it caught.  So, basically, it told me
==> little to nothing about my errors.
==> 
==> Soft Ice - From the same people, but surprisingly worlds better.  You have 
==> to have a certain affinity for assembly language, because this is it's 
==> natural mode.  But we've used it with our c++ code (always interesting to 
==> see how that stuff compiles!) and found NUMEROUS memory errors.  For example:
==> 
==> Soft Ice crashes with an "invalid instruction" at point X.  You see, however,
==> that point X is well within your code space.  Hmm.  Resetting the program, 
==> you look at that address BEFORE you run the program.  It's not illegal, it's
==> ok.  Hmm again.  Set a "break whenever someone writes to this address" 
==> breakpoint and run it.  Bang.  Stops dead in its tracks at point y.  Switch
==> to source mode, and it's stopped right on a strcpy or something like that.  
==> You look at your addresses, and see that you've overwritten a boundary.  
==> 
==> 
==> Duane
==> 
==> Hope it helps,
==>  Duane Morin
==>  Software Development Manager 
==>  Walker Sonix
==>  Worcester, MA 01604
==> 
==> 
==> Date: Tue, 8 Sep 1992 12:28:48 -0400
==> From: cmcl2!world.std.com!levin (Levin F Magruder)
==> To: bergman@panix.com
==> Organization: The World Public Access UNIX, Brookline, MA
==> 
==> I got a simple to use two-filer from the Dr. Dobbs Journal place
==> on compuserve.  It just tracks calls to malloc, alloc, strdup,
==> realloc and free, and creates a log file.  It works.
==> 
==> 
==> From: cmcl2!TRICERATOPS.SOAR.CS.CMU.EDU!gap
==> To: Mark Bergman <bergman@panix.com>
==> Date: Tue, 8 Sep 92 15:57:34 EDT
==> 
==> I have a memory allocation package that runs somewhat slowly but 
==> finds every instance of memory problems that I have ever needed. It
==> is written in ANSI C. You can ftp it if you want. It handles
==> the following problems:
==> 
==>     Memory overwrites (at least sequential memory overwrites)
==>           at time memory is freed.
==>     Freeing memory not allocated or freeing memory twice.
==>     Not Freeing memory.
==>     Using information in an already Freed memory block.
==> 
==> It normally reports the infraction, along with the file name
==> and address of the call that allocated the memory block.
==> 
==> If you would like to ftp it then I need to set up the FTP
==> directory and so forth. However, I would be willing to do
==> so.
==> 
==> Gary
==> 
==> From uupsi3!@martha.utcc.utk.edu:ilic@utkux1.utk.edu Wed Sep  9 00:18 EDT 1992
==> Date: Tue, 8 Sep 92 23:57:46 -0400
==> From: cmcl2!utkux1.utk.edu!ilic
==> To: bergman@panix.com (Mark Bergman)
==> 
==> if your code is portable you might try memfence.c.  It is PD but it 
==> runs under almost  anything but DOS.  It catches all bad pointers by 
==> [                           ^^^^^^^  ]
==> using sbrk() and setting protected memory pages right after and before your 
==> arrays.  It is good. 
==> 
==> ilic@hickory.engr.utk.edu
==> 
==> Date: Wed, 9 Sep 92 21:03 EDT
==> From: cmcl2!ais.org!draper (Patrick Draper)
==> 
==> I've used Bounds checker, and it's a disaster, because our application
==> doesn't cause the memory exceptions. The errors occur somewhere inside a
==> third party library, usually.
==> 
==> Also, Memcheck is also a disaster, because it doesn't check errors that I
==> tend to make. It *will* do checking on function calls, but if you assign a
==> pointer or copy memory outside a function, you can still bypass that. It's
==> also expensive for what it does. I might pay 50 bucks for it, but not 129.
==> 
==> 
==> Date: Wed, 9 Sep 92 22:23:28 EDT
==> From: Levin F Magruder <cmcl2!world.std.com!levin>
==> 
==> Here is the malloc debugging stuff from DDJ.  
==> 
==> [ File Deleted ]
==> 
==> [ I tried the enclosed debugging aids, but with little success. I'm
==> looking for something a little more turn-key, enve if that means $$ ]
==> 
==> Date: Sun, 27 Sep 92 00:14:14 -0400
==> From: cmcl2!ultrix.ramapo.edu!smclewin (Scott M McLewin)
==> 
==> My company uses Super Malloc in one of thier applications.  It is not a 
==> memory checker, but a sort of replacement for the malloc/free functions
==> in C.  It provides better memory management to avoid fragmentation, but
==> does not give reports on misuse of pointers, etc.  The product is 
==> simply an .OBJ file to link into your project, and the manual is 
==> pretty small ( under 10 pages).  I recommend it if your DOS app 
==> allocates and frees lots of little blocks.
==> 
==> I am presently beta tesing (gamma now) Bounds-Checker.  Their version
==> 2 is simply AWESOME!  If you write in C under DOS, I strongly urge you
==> to use it.  It watches for writes past arrays (local, global, heap),
==> writes to your code, jumps out of your code space, reports on 
==> memory leakage, warns you if you use a free'd pointer.  It will even
==> do all this on a TSR....  I am quite impressed by it.   
==> 
==> In a month or so I will be beta testing soft-ice, their DOS debugger.
==> I used their version 2.5 breifly and found it quite powerful.  Even
==> when the program was hung solid Soft-Ice was still able to activate
==> and see what happened.  Soft-Ice and the new Bound-Checker together
==> will be heaven.
==> 
==> Scott M McLewin
==> 
==> Date: Mon, 28 Sep 92 08:14:38 -0500
==> From: Rick Huff <cmcl2!billnext.tamu.edu!rick>
==> 
==> > 	Bounds-Checker	Nu-Mega Technologies, Inc.
==> 
==> I used this product two years ago before I got into doing Windows  
==> development.  It is great!  It works well do find bugs that you know  
==> about, but it is also very useful to leave the hooks in while you are  
==> doing in-house testing to find bugs that you didn't know about.  
==> 
==> 
==> I hope that this helps.
==> --
==> Rick Huff, Systems Analyst (409) 845-8454 (rick@billnext.tamu.edu)
==> CSC, Computing Account Services, Texas A&M University
==> 
==> Date: Mon, 28 Sep 92 12:05:08 GMT
==> From: bryan@stiatl.salestech.com (Bryan Donaldson)
==> 
==> About BoundsChecker from NuMega,  the last time I heard from them this product 
==> did not check dynamically allocated memory.  BoundsChecker is a Device-Driver/
==> TSR-type program which loads at boot up.  When a program is loaded using
==> its special command, it will check that your code doesn't get overwritten and
==> that local variables and static variables are not overwritten.
==> 
==> So the bootom line is, check with NuMega again about this.  By the way, I have
==> version 1.11.
==> 
==> Bryan Donaldson
==> 
==> From: cmcl2!wugate.wustl.edu!chris.lincoln%travel (Chris Lincoln)
==> Date: Sun, 27 Sep 92 11:37:00 -0500
==> Organization: Travel Online, St. Louis, MO
==> 
==>            Bounds-Checker  Nu-Mega Technologies, Inc.
==>            ^^^^^^^^^^^^^^  I've got 1.0.  2.0 now handles scads more
==>                            exceptions, like the normal heap errors.  It
==>                            also catches overwrites by library routines.
==>                            I would definately buy BC again.  Excellent
==>                            product.
==> 
==> Chris Lincoln
==> 
==> chris.lincoln@travel.com
==> 
==> From: cmcl2!adam.mit.edu!scs (Steve Summit)
==> 
==> I have written such a dbmalloc library (not the one you've heard
==> about).  It should be quite portable; I've used it under Unix
==> (several machines, several compilers) and MS-DOS (Microsoft C).
==> Write back if you're interested in a copy.
==> 
==> 					Steve Summit
==> 					scs@adam.mit.edu
==> 
==> Date: Sun, 27 Sep 92 12:31:44 EST
==> From: cmcl2!f824.n107.z1.fidonet.org!John.Larson (John Larson)
==> 
==> Multiscope Debuggers for Dos or Windows are both excellent debuggers which run
==> under Windows or as a Character Mode dos application.  These guys offer a post
==> mortem debugger and C library called MED which allow you to create CORE DUMP
==> files which can then be loaded into the debugger to show you the state of the
==> program at the time of the crash. You can view this PostMortem dump in context
==> of the source code just as if you were running the debugger during the
==> development phase.  The MED facility can be used with or without adding
==> special code to your program.  However, with the use of the associated
==> libraries you can do things like force a dump during runtime when ever you
==> feel it may be necessary.
==> 
==>  John Larson - Internet: John.Larson@f824.n107.z1.ieee.org
==> 
----
Mark Bergman    (Biker, Stagehand, (former) Unix user support grunt)
718-855-9148

bergman@panix.com
{cmcl2,uunet}!panix!bergman
Newsgroups: comp.os.msdos.programmer