A1. Purify is available on any of the Solaris machines in the Leland cluster.

To run Purify, you should create a new target in your Makefile that runs Purify while linking your program. For Cs244a, the convention is to use the same name as your regular executable with .purify appended to the end. For example:

ftpcopy.purify: ftpcopy.o
	purify gcc -o ftpcopy.purify ftpcopy.o

Your program should compile and link as usual. When you run the Purify'ed version, however, you will get another window that will contain all of the Purify diagnostic messages about your program. These messages contain a three-letter code, a stack trace showing where the error occurred, and information about the memory associated with the error. Some of the common codes you will see are:

UMR	Uninitialized memory read. Your program attempted to read a value from memory that was never given a value.
ABR	Array Bounds Read. Your program attempted to read from memory before or after a declared array.
FIU	File In Use. Your program left a file descriptor open at exit.

More of these codes are explained in the on-line documentation.

Q2. The assignment says I have to turn in a purify.output file, but the output goes to a window so I can't redirect it. How to I get the output to go to a file?

A2. You need to set a run-time option for Purify to tell it to send the output to a file. From the shell prompt enter the command

setenv PURIFYOPTIONS "-windows=no -log-file=purify.output"

Now run your Purify'ed program again. To revert to the behavior of popping up the window (which is easier to navigate in), use

unsetenv PURIFYOPTIONS

Q3. I can't run Purify. Either when I compile or when I run my program, I get all sorts of unfriendly messages about not being able to write into a read-only file system. What's the problem?

A3. Purify has to instrument all of the libraries that are linked with your program as well as the program itself (so it can catch errors that occur in the library code that might have been caused by the application). Normally, these instrumented libraries are cached in the Purify installation directory. The problem is that if you use a library that isn't already instrumented, Purify tries to instrument it for you. Since you can't write to that directory, Purify fails.

To get around this, you can change where Purify caches the libraries. Add the option -cache-dir=/tmp to your Purify command line in the Makefile; for example:

ftpcopy.purify: ftpcopy.o
	purify -cache-dir=/tmp gcc -o ftpcopy.purify ftpcopy.o

This will cause your compilation to be a little slower the first time around since it has to re-instrument all of the libraries you link again. However, it will solve the problem.

Also, please copy the error messages you originally got into an e-mail message to your TA. This allows us to let the Leland maintainers know what libraries need to be in the system cache directory.

Q4. I'm getting a lot of UMR errors that I don't think my program is causing. We have to turn in a program that doesn't have any Purify errors. How do I get around these?

A4. There are some bugs in the socket libraries which can cause an excessive number of UMR's to show up in your Purify output. You can consider these errors to be not your fault if

1. The error happens inside of a network system call (bind, accept, etc.)
2. The accessed memory was allocated from within a network system call.

You can tell Purify to ignore these errors by creating a .purify file in the same directory as your program. You add lines to .purify to supress individual messages. For example;

suppress UMR ...;res_search
suppress UMR ...;nss_search

These two lines tell Purify to ignore UMR's that occur underneath of the functions res_search and nss_search. These lines are a good start for your .purify.

A .purify file will be required by the submission program.

Q5. I get a file descriptor in use error that comes from the socket libraries (/etc/.name_service_door). How do I supress it?

A5. Purify only allows to supress all or none of the file descriptor in use errors. Therefore you should just ignore this error, since you want to be able to know if your code leaves any descriptors open.

Q6. When I issue "make all.purify" for the echodemo example, I see a message that says "In order for Rational PurifyPlus to work properly, you must source the appropriate shell resource file in /usr/pubsw/etc/rational..." How do I fix this?

A6. If you're using csh or tcsh, you can source the csh script with

source /usr/pubsw/etc/rational/purifyplus_setup.csh

A7. This behaviour apparently started with recent versions of g++. The warnings seen on the leland systems mostly apply to C++ code. Since we're using standard C in this class, you should have no problems and can just ignore these warnings.

Q8. When I run my purify'ed executable, I get a cryptic message like "ld.so.1: ./server.purify: fatal: libsocket.so.1_pure_p3_c0_105022037_58_32_2171404S: open failed: No such file or directory." What's going on?

A8. Assuming you're building instrumented libraries in the /tmp directory as recommended above, this happens when the /tmp directory is periodically cleared. If you rebuild your purify'ed application (e.g. make ftpcopy.purify), the problem should go away.