NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/os/msdos/programm/11770

Internet Message Format | 1993-01-03 | 11.6 KB

Xref: sparky comp.os.msdos.programmer:11770 comp.lang.c:19160 alt.msdos.programmer:3079
Path: sparky!uunet!stanford.edu!rutgers!cmcl2!panix!bergman
From: [e-mail] (Mark Bergman)
Newsgroups: comp.os.msdos.programmer,comp.lang.c,alt.msdos.programmer
Subject: C Memory Debuggers (SUMMARY)
Message-ID: <[e-mail]>
Date: 4 Jan 93 00:50:39 GMT
Organization: Panix Public Access Internet & Unix, NYC
Lines: 252

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:

    [e-mail]
    [e-mail] (John Larson)
    Levin F Magruder <cmcl2!world.std.com!levin>
    Rick Huff <cmcl2!billnext.tamu.edu!rick>
    [e-mail] (Bryan Donaldson)
    [e-mail] (Chris Lincoln)
    [e-mail] (Patrick Draper)
    [e-mail] (Jon Freeman)
    [e-mail]
    [e-mail]
    [e-mail] (Janos Haide)
    [e-mail] (euphausia superba)
    schunix![e-mail] (Duane Morin)
    [e-mail] (Steve Summit)
    [e-mail] (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: [e-mail]
==> 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 <[e-mail]>
==> 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:[e-mail] Wed Sep  9 00:18 EDT 1992
==> Date: Tue, 8 Sep 92 23:57:46 -0400
==> From: cmcl2!utkux1.utk.edu!ilic
==> To: [e-mail] (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.
==>
==> [e-mail]
==>
==> 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 [phone] ([e-mail])
==> CSC, Computing Account Services, Texas A&M University
==>
==> Date: Mon, 28 Sep 92 12:05:08 GMT
==> From: [e-mail] (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
==>
==> [e-mail]
==>
==> 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
==>                     [e-mail]
==>
==> 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: [e-mail]
==>
----
Mark Bergman    (Biker, Stagehand, (former) Unix user support grunt)
718-855-9148

[e-mail]
{cmcl2,uunet}!panix!bergman