1     
ABR: array bounds read数组越界读

1.1     
介绍

An ABR message indicates that your program is about to read a value from before or after a block or static data item.

An ABR message can be caused by any of the following:

–  
Making an array too small, for example failing to account for the terminating NULL in a string

–  
Being off by one in copying elements up or down an array

–  
Forgetting to multiply by sizeof(type) when allocating for an array of objects

–  
Using an array index that is too large or negative

–  
Failing to NULL terminate a string

1.2     
典型案例

（待补充）

2     
ABW: array bounds write

An ABW message indicates that your program is about to write a value before or after a block or static data item.

An ABW message can be caused by any of the following:

–  
Making an array too small, for example failing to account for the terminating NULL in a string

–  
Being off by one in copying elements up or down an array

–  
Forgetting to multiply by sizeof(type) when allocating for an array of objects

–  
Using an array index that is too large or negative

–  
Failing to NULL terminate a string

 

3     
BWL: late array bounds write

An ABWL message indicates that your program wrote a value before or after a block or static data item.

The error is similar to an
ABW. The difference is that
an ABWL is not detected immediately when the error occurs, but when an object is freed or when a leak scan is initiated. Further, ABWL errors are detected only for dynamically allocated blocks (that is, when malloc is used).

ABWL errors are detected only on AIX platforms, and only when the options
-late-detect-logic
and -selective
are set. They typically occur when a module that has been excluded does something that would ordinarily cause an ABW. Because the excluded module is not fully instrumented, Purify cannot detect the error when it actually occurs. Instead, Purify detects the
error later, when the object is freed or when a leak scan is initiated.

4     
BRK: misuse of brk or sbrk

A BRK message indicates that your program is using brk or sbrk directly to allocate memory. Use of brk or sbrk is incompatible with the use of most implementations of malloc and free.

 

5     
BSR: beyond stack read

A BSR message indicates that a function in your program is about to read beyond the stack pointer.

A BSR message is commonly caused by a function returning a pointer to a local variable that has gone out of scope. If the caller attempts to use that variable, it can result in a BSR message. To keep the value
valid after the called function returns, make such variables static.

6     
BSW: beyond stack write

A BSW message indicates that a function in your program is about to write beyond the stack pointer.

A BSW message is commonly caused by a function returning a pointer to a local variable that has gone out of scope. If the caller attempts to use that variable, it can result in a BSW error. To keep the value
valid after the called function returns, make such variables static.

Note:

–  
Unlike other write errors, such as an ABW,
this is not a corrupting
error, since it is always legal to write a value beyond the end of the stack. However, values beyond the current stack pointer are subject to change without notice. For example, if your program takes a context switch or a signal, the value written by this
access might not be reliably re-read.

7     
COR: core dump imminent

A COR message indicates that your program has received a signal that is normally fatal, and that does not have user-level signal handlers installed.

This is an example of a core dump due to a bad pointer—either bad pointer arithmetic or pointer corruption (indicated by the preceding
IPR).

To turn off COR messages for signals that you handle within your program, use the
-handle-signals and -ignore-signals options.

Notes:

–  
At times, an application that runs well without Purify can core dump when you use Purify. This is because Purify tends to magnify the existence of a fatal problem and as a result core dumps. Although the application doesn't normally core dump, this type of
problem is very likely to core dump in the field, on a different system, or even sporadically on the current system.

In most cases the core dump is a result of a fatal
error (NPW
or  ZPW, for
example) that Purify has detected. The fatal error is usually reported just before the core message. Fixing this fatal error will fix the core dump.
 

–  
Non-fatal signals that have a user-defined signal handler are reported not as a COR but as a
SIG. This is
because the user-defined signal handler may handle the signal and allow program execution to proceed normally, without a core dump or termination of the program.

8     
FIU: file descriptors in use

An FIU message describes file descriptors that are in use by your program.

To generate a list of file descriptors in use, set the option
-purify-fds-inuse-at-exit=yes
(the default), or the API functionpurify_new_fds_inuse,
or purify_all_fds_inuse.

Each FIU message describes what is known about the origin of one open file descriptor. If you see multiple descriptors for the same file, or from the same call chain in the program, you should be concerned
that you have a file descriptor leak, and your program might run out of file descriptors.

For more information about file descriptor leaks, click

9     
FMM: freeing mismatched memory

An FMM message indicates that your program is deallocating memory using a function from a different family than the one used to allocate the memory.

An FMM error can occur when you use
new[] to allocate memory and delete to free the memory. You should use
delete[] instead, otherwise the destructor associated with the memory cannot be run. Purify reports an FMM message when your program allocates memory from one family of APIs and then deallocates the memory from a mismatching
family. Purify checks these families:

new/delete
new[]/delete[]
malloc/free
calloc/free
realloc/free
XtMalloc/XtFree

10 
FMR: free memory read

An FMR message indicates that your program is about to read from heap memory that has already been freed.

An FMR message can be caused by reading via a dangling pointer to a block of memory that has already been freed. It could also be the result of indexing far off the end of a valid block, or using a completely
random pointer that happens to fall within the heap segment.

11 
FMW: free memory write

An FMW message indicates that your program is about to write to heap memory that has already been freed.

An FMW message can be caused by writing via a dangling pointer to a block of memory that has already been freed. It could also be the result of indexing far off the end of a valid block, or using a completely
random pointer that happens to fall within the heap segment.

12 
NH: freeing non-heap memory

An FNH message indicates that your program is calling
free with a memory address that is not in the heap (memory in stack, data or bss).

An FNH error often occurs due to confusion about pointer ownership. Look for pointers to strings or objects that are normally allocated on the heap being initialized with pointers to constants in the program
data or text segments, or on the stack. This FNH error is caused by attempts to free such addresses.

13 
FUM: freeing unallocated memory

An FUM message indicates that your program is trying to
free unallocated memory (duplicate free or free of bad heap pointer).

An FUM error often occurs due to confusion about pointer ownership. Only the owner should free heap objects.

If there are many references to a heap object with no one reference being clearly the longest lived, the object referenced might have a reference count. Failure to maintain the reference count properly can
also lead to this error.

14 
IPR: invalid pointer read

An IPR message indicates that your program is about to read from an address that is outside any valid segment of your program. Valid segments include program text, data, heap, stack,
mmap'd regions, and shared memory. This usually results in a segmentation violation.

IPR messages are similar to
NPR and
ZPR messages, except
that they indicate an invalid reference to memory outside of the zeroth page.

15 
IPW: invalid pointer write

An IPW message indicates that your program is trying to write to an address that is outside any valid segment of your program. Valid segments include program text, data, heap, stack,
mmap'd regions, and shared memory. This usually results in a segmentation violation.

IPW messages are similar to
NPW and
ZPW messages, except
that they indicate an invalid reference to memory outside of the zeroth page.

16 
MAF: malloc failure

An MAF message indicates that
malloc has failed—you have run out of swap space for the heap to grow. After the message is delivered,
malloc returns NULL in the normal manner.

Ideally, programs should handle out-of-swap conditions gracefully, but often do not. If your program next generates an
NPR,
NPW,
ZPR or
ZPW, and then a
COR, a caller of
malloc has failed to check the return status and is dereferencing the
NULL pointer.

17 
MIU: memory in use

An MIU message describes heap memory that you are currently using (memory to which there is a pointer).

To generate a list of memory blocks in use, use the API function
purify_new_inuse or
purify_all_inuse, or set the option
-inuse-at-exit=yes.

18 
MLK: memory leak

An MLK message describes heap memory that you have leaked. There are no pointers to this block, or to anywhere within this block.

To generate a list of leaked memory blocks, use the API function
purify_new_leaks or
purify_all_leaks, or set the
option -leaks-at-exit=yes
(the default).

A memory leak is caused when the last pointer referencing a block of memory is cleared, changed, or goes out of scope. If the section of the program where the memory is allocated and leaked is executed repeatedly,
you might eventually run out of swap space. This is a serious problem for long-running applications.

Memory that is allocated once, referenced by a pointer (perhaps static or global) and never freed is not a leak and does not generate an MLK message. Since it is allocated only once, you cannot run out of memory
during extended use of the program.

19 
MRE: malloc reentrancy error

An MRE message indicates that a reentrant call to
malloc, free, or a related function has been made. Since most default
malloc implementations are not reentrant, this will likely cause problems.

Note:

• A number of C library functions call malloc as a side effect. Avoid using these in interrupt/signal handlers.

20 
MSE: memory segment error

An MSE message indicates that your program is attempting to address a piece of memory that spans potentially non-contiguous segments of memory. The segments identified include the text segment, the data segment,
the heap, the stack and memory mapped regions.

An MSE message can be caused by any of the following:

• Calling a string or block-copy function with too large a size on a block of memory near the end of the data segment, so that the access spills into the heap. For example, calling strlen for a string not properly
  terminated can have this effect.
• Incorrect size calculation for read or write buffers, leading to requests for transactions with buffers of negative or large size.
• Infinite recursion, causing stack overflow.

21 
NPR: null pointer read

An NPR message indicates that your program is about to read from address zero (read from a
NULL pointer). An SEGV signal will result.

One common cause of an NPR error is failure to check return status for a function expected to return a pointer to a string or an object. If the function returns
NULL on failure, use of the NULL pointer leads to an NPR error.

Note:

• HP-UX can be configured so that NPR errors are not fatal. However, they still represent serious errors. An SEGV happens only if you use the -z compiler option.
  
• On AIX, not all NPR errors are fatal. The AIX compiler regularly generates code that legally accesses NULL values in order to achieve cache line optimization. To disable NPR errors, set the option
  -ignore-npr to yes.

22 
NPW: null pointer write

An NPW message indicates that your program is about to write to address zero (store to a
NULL pointer). An SEGV signal will result.

One common cause of an NPW error is failure to check return status for a function expected to return a pointer to a string or an object. If the function returns
NULL on failure, use of the NULL pointer leads to an NPW error.

23 
PAR: bad parameter

A PAR message indicates that your program has called a common library function, such as
write, with a bad parameter. Typically Purify warns about bad parameters which involve pointer abuse, such as passing
NULL as the buffer to read or write.

24 
PLK: potential memory leak

A PLK message describes heap memory that you have possibly leaked;  you cannot however be sure that the memory has been leaked because you have pointers only to the middle of the region.

In this example, 100 bytes are reported as potentially lost, not leaked.
ptr does not point to the start of the block; it points 50 bytes into it. The
free on line 10 assures that there is no leaked memory.

Memory in use can sometimes appear as a PLK if the pointer returned by
malloc is offset. A common cause is referencing a substring within a large string. Another example is when a pointer to a C++ object is cast to the second or later base class of a multiply-inherited object. It is offset
past the other base class objects.

Truly leaked memory can sometimes appear as a PLK, if some non-pointer integer within the program space, when interpreted as a pointer, points within an otherwise leaked block of memory. This is rather rare.
Inspect the code to differentiate between these causes of PLK reports.

25 
PMR: partial UMR

A PMR message indicates that a potential UMR is occurring in an alignment pad. These errors are usually harmless, and are
suppressed
by default.

Notes:

• PMR messages are not reported on 32-bit Solaris systems.
• You can display PMR messages if you choose. For more information, see
  Removing and editing suppressions.

26 
SBR: stack array bounds read

An SBR message indicates that your program is about to read across stack frame boundaries. This is similar to an
ABR, but concerns
a local variable instead of a malloc'd block.

An SBR error can be caused by any of the following:

• Making an automatic array too small, for example, failing to account for the terminating NULL in a string
  
• Forgetting to multiply by sizeof(type) when allocating for an array of objects
  
• Using an array index that is too large or negative
  
• Failing to NULL terminate a string
  
• Being off by one in copying elements up or down an array
  
• Passing too few arguments to a function
  

Notes:

• If the 'off-by-one' read in the example does not cause an SBR message on your system, your compiler may be padding the local variables, or it may be allocating them in a different order than the example presumes.
• On SPARC systems, Purify also detects access across stack frames.
•  Purify does not support SBR messages on HP-UX or Linux systems.

 

27 
SBW: stack array bounds write

An SBW message indicates that your program is about to write across stack frame boundaries. This is similar to an
ABW, but concerns
a local variable instead of a malloc'd block.

An SBW error can be caused by any of the following:

• Making an automatic array too small, for example failing to account for the terminating NULL in a string
  
• Forgetting to multiply by sizeof(type) when allocating for an array of objects
  
• Using an array index that is too large or negative
  
• Failing to NULL terminate a string
  
• Being off by one in copying elements up or down an array
  

Notes:

• If the 'off-by-one' write in the example does not cause an SBW message on your system, your compiler may be padding the local variables, or it may be allocating them in a different order than the example presumes.
• On SPARC systems, Purify also detects access across stack frames.
•  Purify does not support SBR messages on HP-UX or Linux systems.

28 
SIG: signal message

An SIG message indicates that your program has received a signal.

By default, Purify notifies you only about signals that normally terminate the program. See the
-handle-signals
and -ignore-signals options.

Note:

• A signal that is normally fatal and that does not have user-level signal handlers installed results in a
  COR message.

29 
SOF: stack overflow

An SOF message indicates that your program has overflowed the stack, probably due to runaway recursion.

30 
UMC: uninitialized memory copy

A UMC message indicates that an uninitialized value is being copied from one memory location to another (e.g. an assignment). Such copies are normally harmless copying of padding fields in structures.

By default, Purify suppresses UMC messages in the global
.purify file because they can generate excessive output and reduce your program's performance. To unsuppress UMC messages, comment out the line in the
<purifyhome>/.purify file that reads:

suppress umc *

by adding a hash mark (#) at the beginning of the line:

#suppress umc *

or add the line:

unsuppress umc *

to the .purify file in the directory where your program resides.

31 
UMR: unitialized memory read

A UMR message indicates that your program is about to read uninitialized memory.

Often, uninitialized memory will be zero, especially during unit testing. Your program will seem to perform correctly but the UMR can eventually cause incorrect behavior.

It is common, and correct behavior, for a program to copy uninitialized data from one variable to another. A frequent case is during structure assignment when the structure being copied has inaccessible padding
bytes. For this reason, Purify does not report UMR messages on copies, but instead reports a (suppressed)
UMC and propagates the uninitialized
status to the destination of the copy.

32 
WPF: watchpoint free

A WPF message indicates that your program is about to
free a block of memory containing a watchpoint.

33 
WPM: watchpoint malloc

A WPM message indicates that your program is about to
malloc a block of memory containing a watchpoint.

34 
WPN: watchpoint entry

A WPN message indicates that your program has just entered a function that is allocating local variables on the stack in watched memory.

35 
WPR: watchpoint read

A WPR message indicates that your program is about to read from memory that has a read-type watchpoint on it.

36 
WPW: watchpoint write

A WPW message indicates that your program is about to write to memory that has a watchpoint on it.

37 
WPX: watchpoint exit

A WPX message indicates that your program has exited a function that had allocated local variables on the stack in watched memory.

38 
ZPR: zero page read

A ZPR message indicates that your program is about to read from the zero page of memory—read from a bad pointer. An
SEGV signal can result.

A ZPR error can be caused by a failure to check return status for a function expected to return a pointer to a structure or an object. If the function returns
NULL on failure, accessing a structure field from the
NULL pointer leads to a ZPR error.

Note:

• HP-UX can be configured so that ZPR messages are not fatal. However, they still represent serious errors. A SEGV happens only if you use the -z compiler option.
• On AIX, not all ZPR errors are fatal. The AIX compiler regularly generates code that legally accesses NULL values in order to achieve cache line optimization. To disable ZPR errors, set the option
  -ignore-zpr to yes.

39 
ZPW: zero page write

A ZPW message indicates that your program is about to write to the zero page of memory—store to a bad pointer. An
SEGV signal can result.

A ZPW error can be caused by a failure to check the return status for a function expected to return a pointer to a structure or an object. If the function returns
NULL on failure, writing to a structure field of the
NULL pointer leads to a ZPW error.