The bug in debug mode for new calls of VC 6.0

The maintenance project was developed using VC6.0. It was installed on the site and found that it crashed every month, after checking the dmp file, we found that the code corresponding to the new operation in the crt library of VC6.0 caused Microsoft visual Studio/VC98/Crt/Src/dbgheap. c) in this file, the _ heap_alloc_dbg () function uses a long variable to count, once the counter reaches the maximum value of the long type, int 3 will be triggered to interrupt "VC ++ 6.0 new call bug":

 
 

  
  
/* break into debugger at specific memory allocation */ 
  
  
        if (lRequest == _crtBreakAlloc) 
  
  
            _CrtDbgBreak(); 
 
 

This problem is actually very easy to solve. After querying vs2003, it has been changed to this, and this bug has been eliminated:

 
 

  
  
/* break into debugger at specific memory allocation */ 
  
  
        if (_crtBreakAlloc != -1L && lRequest == _crtBreakAlloc) 
  
  
            _CrtDbgBreak(); 
 
 

Logically, it is easy to eliminate this bug, but the problem is that it is the Library of MFC. There are several solutions for online query:

1. Use UE to open msvcrtd. dll, using the hexadecimal editing mode, find the Binary command, and find that there are only two places, replace their 0xCC with 0x90. The problem is solved.

2. Modify the debug report mode. Use _ CrtSetReportMode and _ CrtSetReportFile to block the dialog box popped up by _ CrtDbgBreak. The Code is as follows:

 
 

  
  
_CrtSetReportMode( _CRT_ASSERT, _CRTDBG_MODE_FILE ); 
  
  
_CrtSetReportFile( _CRT_ASSERT, _CRTDBG_FILE_STDOUT ); 
  
  
_CrtSetReportMode( _CRT_ERROR, _CRTDBG_MODE_FILE ); 
  
  
_CrtSetReportFile( _CRT_ERROR, _CRTDBG_FILE_STDOUT ); 
  
  
_CrtSetReportMode( _CRT_WARN, _CRTDBG_MODE_FILE ); 
  
  
_CrtSetReportFile( _CRT_WARN, _CRTDBG_FILE_STDOUT ); 
 
 

3. Use the memory pool and other technologies to reduce the use of new systems.

4. Change the project to the IDE above VS2003 for compilation

First, I tried to use UE to edit the dll and found that I was too lacking in this knowledge and did not know how to change it. I asked a few people who did not understand it, in addition, this solution shields the _ CrtDbgBreak function and may cause other problems.

I tried the second solution with joy, but found that it could not be blocked at all. The pop-up still appeared, and it seems that I can only intercept a part, but I didn't understand why it didn't take effect.

Then I tried to use the memory pool to reduce the usage of new products. I tried the memory pool provided by boost and it was quite easy to use. However, the disadvantage was that this method was a temporary solution, MFC has a large number of new operations.

I tried to compile this code with VS2008, But it generated thousands of errors. It took a very hard time to compile the EXE for a day. The running environment crashes ......

--------------------------------------------------------------------------

Fortunately, we finally found a solution, which is the ultimate solution to be introduced in this article:

I have always thought that the dbgheap. c file is part of mfc and cannot be rewritten! It was accidentally discovered that MFC actually provides the makefile file for recompilation. For details, refer to "re-compile and generate C Runtime Library".

First, modify the bug in the dbgheap. c file, and recompile the C Runtime Library according to the method described in this article. That's all right!

Please note that msvcrtd. the dll is not generated. An error occurs during compilation, but libcmt. lib can be compiled. At last, my project can only use the static link to use the MFC library.

 

This article is from "Hello Snow !" Blog, please be sure to keep this source http://hellosnow.blog.51cto.com/164899/732143