The strcpy function causes the release program to crash.

I recently wrote a small program to read model files. The strcpy function is randomly used to copy the char character array. This array needs to be passed to PostMessage as the parameter of WPARAM. The Code is as follows:

1 char pStrCurrentFileName [MAX_PATH] = ""; 2 std: string strCurrentFileName; 3 4 // if a single prt file path is valid, read 5 if (IsValidModelPath (m_strInputPath) directly )) 6 {7 // code 8 9 strCurrentFileName = GetFileNameWithExt (m_strInputPath); 10 strcpy (pStrCurrentFileName, strCurrentFileName. c_str (); 11: PostMessage (m_hDlg, WM_USER_MSG_SHOWFILENAME, WPARAM (& pStrCurrentFileName), LPARAM (m_strInputPath.size (); 12 13 ReadFile (m_strInputPath ); 14 15 // some code is omitted here 16}

The program runs normally in 64-bit Debug. After compiling the program into 64-bit Release, double-click the exe to run the program. After this part is executed, the program will crash, sometimes a prompt dialog box appears (forgot), which is probably suitable for ntdll. dll. This problem occurs when you read almost all models. Baidu has ntdll. dll. All the original win32api functions call the dll and immediately contact the added strcpy function (because svn is used, there are not many historical versions, and it is also convenient to trace back ^_^ ). Because when I used strcpy, I also thought about whether to use the memcpy function. However, I used strcpy when I didn't think about it. After memcpy is used, replace the 10th line of code:

memcpy(pStrCurrentFileName, strCurrentFileName.c_str(), strCurrentFileName.size());

There is no crash in the running of release. Directly search Baidu for the "mfc program release crash", as mentioned in an article. The excerpt is as follows:

2. Data Overflow

For example:

Char buffer [10];

Int counter;

Lstrcpy (buffer, "abcdefghik ");

If you use strcpy (), lstrcpy (), and other functions, check carefully.

In the debug version, the buffer's NULL overwrites the counter's high position, but unless counter> 16 M, there is no problem. However, in the release version, counter may be placed in the register, so that NULL overwrites the space in the buffer, which may be the return address of the function, leading to access error.

3. The memory allocation methods for DEBUG and RELEASE versions are different.

For example, if you apply for 6 * sizeof (DWORD) = 24 bytes for ele In the DEBUG version, the 32 bytes is actually allocated to you (the debug version is allocated in 32bytes units ), in the release version, 24 bytes are allocated to you (8 bytes for the release version). Therefore, if you write ele [6] In the debug version, there may be no problems, in the release version, access violate exists.

The original Article is: http://blog.csdn.net/fanwenbo/article/details/6067156

It seems that after writing a program, you still need to perform simultaneous testing under release. Many problems that do not occur under debug are reflected in release.

Record the problem first and study it later.