This topic provides help with questions about Purify messages, suppressions, unexpected mixed-case function names, and problems with line numbers.
You have probably run out of swap space. You can build on a machine that has more swap space, or add additional swap space. Purify provides instructions in the full text of the message.
For Solaris, use the command /usr/sbin/swap -s to see how much memory you have. Use mkfile to add swap space.
For HP-UX, use the command /etc/swapinfo to see how much memory you have. (You must be root to run this command.) Use swapon to add swap space.
For IRIX, use the command /sbin/swap -s to see how much memory you have. Use mkfile to add swap space.
For example, when you use /usr/sbin/swap -s on Solaris, you might get:
24592k allocated + 7472k reserved = 32064k used, 11692k available
In this case, the current swap space totals 32064 + 11692K » 44M. You need to add an additional 13 megabytes for a total of 57 megabytes of swap space.
You need to use a machine with more swap space, close down other programs, or add additional swap space. For the commands to add swap space, click .
You might have a dynamic linker deficiency. Try removing the directory within the Purify cache that contains the library that ld.so complains it cannot find. Then rebuild with Purify to rebuild the shared directory and the shared libraries.
You can ignore this message. It indicates that the object file util.o is empty. The source file probably contained #ifdefs that were all false.
This error occurs on Solaris machines if you are using the GNU binutils version of ar because it doesn't put the symbol table in the library. To avoid this error use /usr/ccs/bin/ar. Specify /usr/ccs/bin as the first entry of the PATH variable. If you need to use the GNU version of ar, run binutils' ranlib on the library.
This error occurs on Solaris and HP-UX machines. The message is from the GNU compiler "collector" pre-linker tool. It is the result of Purify inserting itself into the link process before the collector runs and it can be safely ignored.
If an item in the suppression database has a call chain with more function names in it than are recorded in the reports it is comparing against, an exact match is not possible. In such cases, the reports are not suppressed and a warning is issued for the first such instance.
You can control the number of functions in a call chain reported by Purify with the option -chain-length. Set this option to a larger number to ensure your suppressions are recognized.
For example, assume you suppress an error along the following call chain:
foo
bar
baz
As in:
suppress umr foo; bar; baz
Now assume you re-instrument your program with a call chain length of 2:
purify -chain-length=2 cc . . .
When you run your program, the UMR will not be suppressed because the reported call chain is just "foo; bar" and not "foo; bar; baz".
Purify intercepts a number of functions like read and malloc. It changes the name of real definitions to be mixed-case, such as ReAd and MaLlOc, and provides wrapper definitions with the normal names, that do the checking and then call the real definitions.
1 int main {}
2 int worse = 0;
3 int bad;
4
5 worse = bad;
6 worse++;
7 exit(0);
8 }
The variable bad is uninitialized. The uninitialized random value is copied from bad to worse. Then worse, which now contains the random uninitialized value, is incremented. Purify reports that uninitialized memory is used on line 6, but by default does not report that it is copied on line 5.
Many programs copy uninitialized values, but do not use them. An example is a program that uses bcopy to copy structures that contain padding due to data alignment restrictions. Since the program does not use these values it is not in error. Only when an uninitialized value is used in a computation or passed to a function does Purify signal that an error has occurred. For more details, click
A leak occurs when the last reference to the memory is overwritten. After your program is done with a pointer, it is not always immediately overwritten. The pointer variable can be "dead" with respect to your source code, while the memory location or register containing it stays around for a while. This is why purify_new_leaks sometimes shows a leak occurring a few lines after the pointer variable becomes "dead." Of course, this does not affect the malloc location listed in the Purify report.