From: jbuck@forney.eecs.berkeley.edu (Joe Buck) Subject: Re: gcc on linux Date: 7 Jun 1993 19:25:42 GMT
In article <C89EMo.IrI@boulder.parcplace.com> imp@boulder.parcplace.com (Warner Losh) writes:
>I have found that forgiving malloc implementations cause nothing but
>heartache for you when you port to less forgiving implementations.
>They lull you into a false sense of security and make you think that
>your product is more stable than it really is.
>
>Purify helps in this area, but it only runs on Suns. Debugging malloc
>libraries help as well, but not as much as purify. Maybe that would
>make a good linux project: hack together a purify thing... I wonder
>how hard it would be to get one that was fast?
The following package from Brown University might make a good starting
point; perhaps it can be ported to Linux. From a posting to comp.lang.c++:
>From: sdm@cs.brown.edu (Scott Meyers)
Subject: Re: Sentinel vs. Purify -- any comparative studies ?
Message-ID: <1993Jun1.210416.7145@cs.brown.edu>
Sender: news@cs.brown.edu
Organization: Brown University Department of Computer Science
Date: Tue, 1 Jun 1993 21:04:16 GMT
Lines: 93
In article <1993May20.143625.23526@sstl.uucp> will@sstl.uucp
(William Pickles) writes:
|
| We know about two packages that aim to help clean up C++ (and C) programs in
| the area of memory use. Are there others?
Brown University has developed a tool called vmon that offers capabilities
similar to those offered by these products. From the man page:
NAME
vmon, vmemcheck - Dynamic memory checking
SYNOPSIS
vmon [ options ] command
vmemcheck [ options
DESCRIPTION
vmon is a memory checking program. It works by keeping
track of the typestate (c.f. the NIL language developed at
IBM) of each byte of heap and stack memory. The typestate
can be one of Undefined, Uninitialized, Free, or Set. (We
wanted to add Used, but ran out of bits.) In any case, the
program can detect invalid transitions (i.e. attempting to
set or use undefined or free storage or attempting to access
uninitialized storage). In addition, the program keeps
track of heap management through malloc and free and will
report, at the end of the run, all memory blocks that were
not freed and that are not accessible (i.e. memory leaks).
vmon actually is a front end that runs the program with a
special shared library that does the memory monitoring. The
information about heap management and memory problems is
then passed on to vmemcheck either directly through a pipe
or indirectly though a file. vmemcheck is then used to
report the problems in a meaningful way.
Vmon is related to our work on the FIELD programming environment, but it is
currently packaged separately from FIELD (in aard.tar.Z on
wilma.cs.brown.edu). aard.tar.Z is a complete standalone package (i.e.
contains a message server from FIELD and those components of BWE that are
necessary) and does not require FIELD to be available. If FIELD is
available, then it will use it. Vmon requires gnumake to compile (this is
normally part of BWE, but is distributed separately and many people have
their own version of it).
For those unfamiliar with FIELD, here's my standard blurb:
The FIELD programming environment, an extensive set of tools for
programming in C++, C, and Pascal, is available at no cost from Brown
University. Specialized C++ tools include a class browser (cbrowse) and a
debugger that runs on top of dbx or gdb. Both Gnu and AT&T compilers are
supported. FIELD uses the tools of the Brown Workstation Environment
(BWE), which in turn runs on top of X11.
If you'd like more information about FIELD, e.g., what it is, what it can
do, what systems it runs on, etc., send your questions to bwe@cs.brown.edu.
This is the address to which ALL technical correspondence should be sent.
If you'd like to get a copy of FIELD, we have made it available via
"semi-anonymous" ftp. Send your name, business address, phone and fax
number to brusd@cs.brown.edu and we will send you instructions on how to
get FIELD. This address is for distribution information ONLY.
Alternatively, you may fax a request to Kathleen Kirman at 401/863-7657,
but again, this is for distribution information ONLY. (If you don't have
FTP access, it is possible to get tape copy of the software, but there is a
charge for that form of distribution.)
If you'd like to read about FIELD before you get it, consider these
papers:
Steven P. Reiss, "Connecting Tools using Message Passing in the FIELD
Program Development Environment," IEEE Software, July 1990, pp. 57-67.
Steven P. Reiss, "Interacting with the FIELD Environment," Software:
Practice and Experience, 20:S1, June 1990, pp. 89-115.
Steven P. Reiss and Scott Meyers, "FIELD Support for C++," USENIX C++
Conference Proceedings, April 1990, pp. 293-299. Also available
as Brown University Computer Science Department Technical Report
CS-93-03.
Moises Lejter and Scott Meyers and Steven P. Reiss, "Support for
Maintaining Object-Oriented Programs," Proceedings of the Conference on
Software Maintenance, October 1991, pp. 171-178. Updated slightly for
IEEE Transactions on Software Engineering, December 1992. Also available
as Brown University Computer Science Department Technical Report
CS-91-52.
The first two papers above are not available electronically, but the last
two may be retrieved via anonymous FTP from wilma.cs.brown.edu in the
"/pub/techreports" subdirectory.
Scott