1. I can't get mpr to create the log file.

2. I'm using mpr with a C++ program, but I can't get it to create
   the log file.

3. When I try to look at the log file using the tool 'mpr', I get
   weird results.

4. Why is mpr so slow when using options '-f -l' to show file names
   and line numbers ?  How can I speed up mpr, even when not using
   options '-f -l' ?

5. How difficult would it be to add support to mpr to detect memory
   access violations like the commercial tool Purify(tm) does ?

6. When will mpr be ported to platform X ?

7. Why don't you rewrite the whole thing in C for speed ?



1. I can't get mpr to create the log file.

Make sure you've set the environment variable MPRPC properly.
Most people who complain about mpr not working have misread the
examples in DOC and example/README.  You need to use
back-quotes, NOT ordinary quotes, to set MPRPC.

	% export MPRPC=`mprpc a.out`		CORRECT

	% export MPRPC='mprpc a.out'		WRONG
	% export MPRPC="mprpc a.out"		WRONG


Newer shells (e.g. bash) also support the alternate $() syntax to
do this - some people find this easier to digest.

	% export MPRPC=$(mprpc a.out)		CORRECT


Also, make sure that you DO NOT use back-quotes when setting the
environment variable MPRFI.

	% export MPRFI='cat >log'		CORRECT
	% export MPRFI="cat >log"		CORRECT

	% export MPRFI=`cat >log`		WRONG


2. I'm using mpr with a C++ program, but I can't get it to create
   the log file.

First, make sure you've read the answer to question (1).  If you still
get an empty log file, then the most probable reason is that the library
libmpr.a hasn't been linked into your program (even though you may have
listed it on your linker command line.)  For C++ programs, this may happen
if there are no direct calls to malloc(), realloc() or free() in your
program - you are probably using C++'s new and delete operators.  Hence,
there are no unresolved malloc(), realloc() or free() symbols to resolve
when the linker gets to the library libmpr.a.  To test if this is the case,
type the following (replace 'a.out' with the name of your executable)

	% nm a.out | grep mprbt

If you get no match, then libmpr.a has not been linked into your program.

To fix this, you need to create an unresolved reference to malloc().  One
way to do this is to create a dummy file that contains an unresolved
reference to malloc() and link it into your program.

e.g.
	dummy.c:
		extern void *malloc();
		static void *dummy=malloc;

	% cc a.o b.o ... dummy.o ... -lmpr

If you now type the 'nm' command above, you should get a match.

Another, simpler way to force libmpr.a to be linked into your program is to
tell your linker to create an unresolved reference to malloc() (assuming of
course that your linker provides such an option.)  e.g. the GNU linker
provides an option '-u symbol' that you can use to force 'symbol' to be
entered as an undefined symbol.

e.g.
	% cc -umalloc a.o b.o ... -lmpr

If you now type the 'nm' command above, you should get a match.


3. When I try to look at the log file using the tool 'mpr', I get
   weird results.

You have to make sure that the executable program specified as an
argument to tool 'mpr' is the same version that was used to create
the log file.  Otherwise, the program counters that are stored in
the log file may no longer be valid, in which case you will get
very misleading output from mpr.


4. Why is mpr so slow when using options '-f -l' to show file names
   and line numbers ?  How can I speed up mpr, even when not using
   options '-f -l' ?

Support for options '-f -l' used to be slow in versions <1.5, but
should be considerably faster now.  See README.SLOW for details.


5. How difficult would it be to add support to mpr to detect memory
   access violations like the commercial tool Purify(tm) does ?

Very difficult.  mpr was designed to detect memory leaks and memory
allocation patterns only, which is a MUCH simpler task than what tools
like Purify(tm) do.  If you are interested in freely available tools
which try to detect memory access violations, you may want to check
out ElectricFence and Checker.  I have included their current LSM
entries below.

Also, see the section describing GNU malloc's mcheck() in DOC
and the pointer to "The Dynamic Storage Allocation Information
Repository" in README.


LSM entry for Checker:

Begin3
Title:          Checker
Version:        0.8
Entered-date:   05NOV96
Description:    Checker is a malloc debuger, a garbage collector and a
		detector of bad memory access.  It uses code insertion.
		Checker emits a report when a bad memory pointer is used,
		when you read an unitialized buffer...
Keywords:       checker, malloc, debuger, garbage collector, code insertion
Author:         gingold@email.enst.fr (Tristan Gingold)
Maintained-by:  gingold@email.enst.fr (Tristan Gingold)
Primary-site:   sunsite.unc.edu /pub/Linux/devel/lang/c
		569880 bytes  Checker-0.8.tgz
		1528150 bytes  Checker-libs-0.8.1.tgz
		(not yet available) Checker-libg++-0.8.tgz
Alternate-site: 
Original-site:  
Platforms:      Linux v2.0 or later, GCC 2.7.2 (elf), libc 5
Copying-policy: GPL
End


LSM entry for ElectricFence:

Begin3
Title:		ElectricFence
Version:	2.0.5
Entered-date:	20JAN95
Description:	A malloc debugger that uses the virtual memory hardware.
Keywords:	Malloc checker Electric Fence virtual memory overrun debugger
Author: 	Bruce@Pixar.com (Bruce Perens)
Primary-site:	ftp.pixar.com
			25k ElectricFence-2.0.5.tar.gz
			1k  ElectricFence.LSM
Alternate-site: sunsite.unc.edu:pub/Linux/Incoming -> pub/Linux/devel/lang/c
Platforms:	REQUIRES kernel 1.1.83 or above.
Copying-policy:	GPL
End


6. When will mpr be ported to platform X ?

I only have access to a very few platforms.  If you would like
mpr to be ported to a new platform and are willing to give me
Internet access to such a platform for development purposes, I
*may* agree to do the port.

It is not very difficult to port mpr to a new platform.  The
hardest part is figuring how to walk the stack for a particular
architecture;  assuming you have GCC, examining the assembler
output of config/btgcc.c should give you a good hint on how to
do this.


7. Why don't you rewrite the whole thing in C for speed ?

You are a child who hasn't yet learned 'The Unix Philosophy'.  ;^)
