Common memory outliers of VC + +

0 VC + + Common memory outliers

* 0XCCCCCCCC : Used by M Icrosoft ' s C + + debugging Runtime library to mark Uninitialised stack memory * 0XCDCDCDCD : Used by Microsoft ' s C + + debugging Runtime library to mark uninitialised heap memory * 0xfeeefeee : Used by Microsoft's HeapFree () to mark freed heap memory * 0xabababab:used by Microsoft's HeapAlloc () to mark "No Man" la nd "guard bytes after allocated heap memory * 0xabadcafe:a startup to this value to initialize all free memory to Catch Errant pointers * 0xbaadf00d:used by Microsoft's LocalAlloc (lmem_fixed) to mark uninitialised allocated heap Memory * 0xbadcab1e:error Code returned to the Microsoft EVC Debugger when connection are severed to the debugger< /p> * 0xbeefcace:used by Microsoft. NET as a magic number in resource files

The above outliers, the more common is the first three kinds:

　　For 0XCCCCCCCC and 0xcdcdcdcd, in Debug mode, VC will not initialize the stack memory pointers are all filled with 0XCCCCCCCC, when the string look is "Hot hot hot ..." , the uninitialized heap memory pointers are all filled in 0XCDCDCDCD, when the string look is "Tuen Tun Tun ... ". So why does the debugger do this? VC Debug version will automatically initialize the uninitialized pointer to 0XCCCCCCCC or 0XCDCDCDCD, rather than let random values, that is to facilitate our debugging program, if the wild pointer initial value is not deterministic, then each time debugging the same program may appear different results, For example, this time the program is broken, the next time it will be able to run normally, so it is obviously bad for us to solve the bug, so the purpose of the automatic initialization is to let us know at a glance that we have used the uninitialized wild pointer.

　For 0xfeeefeee, it is used to mark the memory that has been freed on the heap. Note that if the memory that the pointer points to is freed, the address of the variable itself is not changed, or the address of the memory pointed to previously. If the pointer is a pointer to a class, and the class contains a pointer variable, the pointer variable in the class is assigned a value of 0xfeeefeee after the memory is freed (typically, the delete operation is performed for C + + classes). If you find a pointer with a value of 0xfeeefeee in the early debugging code, it means that the corresponding memory has been released and our code has gone wrong.

here, there is a VC in Debug and the Release variable initialization problem in mode

As you know, Debug and release do different things when initializing variables, debug is to assign each byte bit to 0XCC, and the assignment of release is approximate to random (I want to be allocated directly from memory, not initialized). This makes it clear that if a variable in your program is referenced without being initialized, there is a good chance of an exception: the use of a control variable will result in a process-oriented inconsistency, and being used as an array subscript will cause the program to crash, and more likely to cause inaccuracies in other variables to cause other errors. Therefore, it is the simplest and most effective way to initialize a default value immediately after declaring a variable, or you will find no place to find it if the project is big. Code errors in the debug mode may be ignored without being detected, such as the debug mode of the array out of bounds also most will not error, in the release of the exposed, this find is more difficult.

　　

1 VC + + Debug Run Normally, release run crashes

I, memory allocation problem

1. The variable is not initialized.

Variables are automatically initialized in debug, but not in release. So: Initialize the variable, class, or struct as much as possible (it's important!) ）。

2. Data overflow Issues

Such as:

Char buffer[10];

int counter;

lstrcpy (buffer, "Abcdefghik");

If you use strcpy (), lstrcpy () functions, please check.

In debug version, buffer null covers the counter high, but unless counter>16m, there is no problem. However, in release version, counter may be placed in the register, so that null overwrites the space under buffer, possibly the return address of the function, which causes access ERROR.

The memory allocation method for version 3.Debug and release is different.

If you are applying ele to 6*sizeof (DWORD) =24bytes in the debug version, you are actually assigned 32bytes (the debug version is allocated in 32bytes), and in the release version, Assigned to you is 24bytes (release version in 8bytes units), so in the debug version if you write Ele[6], there may be no problem, and in release version, there is access violate.

Ii. Assert and verify

1.ASSERT is not compiled in release version.

If you add in these statements the code that you must have in your program,

Like what:

ASSERT (pnewobj = new CMyClass);

Pnewobj->myfunction ();

This time the release version of the pnewobj will not be allocated to the space so the execution of the next statement when the program will report that the program has performed an illegal operation error. Then you can use VERIFY

Iii. parameter issues:

The handler function for the custom message must be defined as follows:

afx_msg LRESULT onmymessage (WPARAM, LPARAM);

The return value must be an HRESULT, or debug will be over, and the release error

Iv. Memory allocation

Ensure consistency in data creation and cleanup: If a DLL provides a function to create data, the DLL should also provide a function to destroy the data. The creation and cleanup of data should be on the same level.

The disaster of V.DLL

People will mix different versions of DLLs caused by the inconsistency image called "Dynamic Connection Library of Hell" (DLL Hell) If your program uses your own DLL please note:

1. You cannot mix debug and release versions of DLLs together. Debug is the debug version, release version is release version.

2. Do not assume that the static connection library will solve the problem, it will only make the situation worse

VI. Debug in the release board:

1. Change the Assert () to VERIFY ().

Find the code that is defined in "#ifdef _DEBUG", and if you need it in the release version, move them out of the definition. Find Trace (...) Code, because the code is not compiled in release. Please check carefully if the code you need in release is not compiled.

2. The different initialization of the variable.

There are differences between the different systems, or between debug/release versions, so initialize the variables.

3. Have you already had a warning at compile time?

Set the warning level to 3 or 4, and then ensure that no warnings appear at compile time.

VII. Change the optimization option under Project Settings "C++/C" to Disbale (Debug).

Compiler optimizations can cause many unexpected errors, please refer to the

Http://www.pgh.net/~newcomer/Debug_Release.htm

1. Also the release version of the software can be debugged

Please make the following changes:

Under Project Settings, set the category to "General" under the "C++/C" item and set the "Debug Info" to "program Database".

Under the Link item, select the Generate Debug Info check box.

The "Rebuild all" approach creates some limitations: You cannot get the value of a variable in an MFC DLL. All DLL works that are used by the software must be modified

Common memory outliers of VC + +