Use IBM Rational purify to Detect application memory errors

Use IBM Rational purify to Detect application memory errors

Memory Errors are other types of errors except program logic errors, which affect the normal operation of the program, cause the program to crash and exit abnormally, or prevent attacks, forming a hidden risk, the attack is triggered only after certain conditions are met. Once the attack occurs, the program crashes or the running result fails.

Common memory errors include stack memory access out-of-bounds (also called array subscript out-of-bounds, subscript overflow), heap memory out-of-bounds, memory leakage, uninitialized memory, and access to illegal memory areas.
Stack memory access out-of-bounds and heap memory out-of-bounds. In most cases, running results are incorrect, which is easy to detect.
Memory leakage is a hidden error and is not easy to detect. When too many memory leaks cause depletion, it will be discovered.
Non-initialized memory often leads to no problem in program debug compilation. Once release is run, errors will occur. Therefore, when debugging is possible, but a release error occurs, it is best not to doubt that the problem is caused by the compiler, which is often caused by code problems,
The Error Code cannot be found under release. Instead, you have to go left and right (friend, have you ever seen the car mobilization ?), In debug, with tools such as boundschecker and IBM Rational purify, all memory errors under debug are solved, and then compiled under release. I can ensure the possibility of 90%: the problem is solved.

Next I will introduce IBM Rational purify plus

IBM Rational purify Plus is a member of the IBM Rational family. using the patented "code injection" technology, it can inject daemon code into the code for VC ++ compiled programs, monitor memory usage and timely report memory errors.

It is easy to use. Taking VC ++ 6 as an example, first compile your program in debug mode, then run purify, run your program in purify, and purify will automatically inject code, all the DLL files called by the program will also be injected with the daemon code (this is better than boundschecker, and boundschecker only injects the current project). In this way, not only can the program itself be identified, the problem with the Linked Library it calls will also be identified (imagine if your program architecture is a main program with a large number of dynamic libraries developed by yourself, how convenient it is to use purify .).

Since the compilation of the debug version of VC ++ 6 contains the file path, line number, and other information of the source file, purify can accurately match the problematic assembly code with the source file, it is very accurate to locate errors in source code.

For the VC ++ 6 release version, most of the memory error checking by purify is invalid. You can only find the access to the illegal memory zone. This Windows version can also be found, however, the error message of purify can indicate the cause of the error, or even tell you what function is causing it, such as strcpy, it is much better than the Error Report of windows, just like tianshu. Therefore, we recommend that you use purify.