Article View: comp.os.msdos.programmer
Article #6271C Memory Debuggers (SUMMARY)
From: Mark Bergman
Date: Mon, 04 Jan 1993 00:50
Date: Mon, 04 Jan 1993 00:50
252 lines
12005 bytes
12005 bytes
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
Technical Details
Message-ID:
<C0B10F.A2H@panix.com>Path:
arc1-ca.pugleaf.net!sparky!uunet!stanford.edu!rutgers!cmcl2!panix!bergmanShow Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!stanford.edu!rutgers!cmcl2!panix!bergman From: bergman@panix.com (Mark Bergman) Newsgroups: comp.os.msdos.programmer,comp.lang.c,alt.msdos.programmer Subject: C Memory Debuggers (SUMMARY) Message-ID: <C0B10F.A2H@panix.com> Date: 4 Jan 93 00:50:39 GMT Organization: Panix Public Access Internet & Unix, NYC Lines: 252