VC++ 6.0 access violation when run in debugger

问题:

I am trying to add enhancements to a 4 year old VC++ 6.0 program. The debug build runs from the command line but not in the debugger: it crashes with an access violation inside printf(). If I skip the printf, then it crashes in malloc() (called from within fopen()) and I can't skip over that.

This means I cannot run in the debugger and have to rely on the old printf statements to see what's going on. This obviously makes it a lot harder.

Any idea why printf() and malloc() would fail when running under the VC++ debugger? I am no good at this low level stuff!

Here is the call stack after the access violation:

_heap_alloc_dbg(unsigned int 24, int 2, const char * 0x0046b3d8 `string', int 225) line 394 + 8 bytes _nh_malloc_dbg(unsigned int 24, int 0, int 2, const char * 0x0046b3d8 `string', int 225) line 242 + 21 bytes _malloc_dbg(unsigned int 24, int 2, const char * 0x0046b3d8 `string', int 225) line 163 + 27 bytes _lock(int 2) line 225 + 19 bytes _getstream() line 55 + 7 bytes _fsopen(const char * 0x00468000 `string', const char * 0x00466280 `string', int 64) line 61 + 5 bytes fopen(const char * 0x00468000 `string', const char * 0x00466280 `string') line 104 + 15 bytes open_new_log(const char * 0x00468000 `string') line 66 + 14 bytes log_open(const char * 0x00468000 `string', int 0) line 106 + 9 bytes Xlog_open(const char * 0x00468000 `string', int 0) line 51 + 13 bytes service_start(unsigned long 1, char * * 0x009a0e50) line 3152 + 12 bytes service_init2(char * 0x00471fcc char * NTPROGRAM, char * 0x004723c4 char * NTSERVICE, char * 0x00466540 `string', unsigned long 1, char * * 0x009a0e50) line 508 + 13 bytes service_init(char * 0x00471fcc char * NTPROGRAM, char * 0x004723c4 char * NTSERVICE, unsigned long 2, char * * 0x009a0e50) line 548 main(unsigned long 2, char * * 0x009a0e50) line 3131 mainCRTStartup() line 206 + 25 bytes KERNEL32! 7c817067() 

Here is the debug dissassembly up to the operation that fails:

0041EA7E   jmp         _heap_alloc_dbg+2B3h (0041eb23) 0041EA83   mov         edx,dword ptr [_lTotalAlloc (004b4294)] 0041EA89   add         edx,dword ptr [nSize] 0041EA8C   mov         dword ptr [_lTotalAlloc (004b4294)],edx 0041EA92   mov         eax,[_lCurAlloc (004b429c)] 0041EA97   add         eax,dword ptr [nSize] 0041EA9A   mov         [_lCurAlloc (004b429c)],eax 0041EA9F   mov         ecx,dword ptr [_lCurAlloc (004b429c)] 0041EAA5   cmp         ecx,dword ptr [_lMaxAlloc (004b42a0)] 0041EAAB   jbe         _heap_alloc_dbg+249h (0041eab9) 0041EAAD   mov         edx,dword ptr [_lCurAlloc (004b429c)] 0041EAB3   mov         dword ptr [_lMaxAlloc (004b42a0)],edx 0041EAB9   cmp         dword ptr [_pFirstBlock (004b4298)],0 0041EAC0   je          _heap_alloc_dbg+25Fh (0041eacf) 0041EAC2   mov         eax,[_pFirstBlock (004b4298)] 0041EAC7   mov         ecx,dword ptr [pHead] 0041EACA   mov         dword ptr [eax+4],ecx 

Here is our source for that calls fopen() and fails in malloc()

FILE *open_new_log( const char *logfile ) {     FILE *fp;     int retry = 0;      while( ( fp = fopen( logfile, "w" ) ) == NULL && ++retry < 300 )         Sleep( 1000 );      return( fp ); } 

The error I get is

Unhandled exception inPISCOOP.exe: 0xC00000005: Access Violation 

Regards,

--- Alistair.

回答1:

You can use _CrtSetDbgFlag() to enable a bunch of useful heap debugging techniques. There's a host of other CRT debugging functions available that should help you track down where your problem is.

回答2:

When run from the debugger, a different heap is used; this is referred to as the debug heap. This has different behaviour from the heap used outside the debugger, and is there to help you catch problems like this one.

Note that the Win32 "debug heap" is distinct from the VC++ "debug heap"; both are intended to do more or less the same thing, however. See this article which describes the difference in behaviour when you run the app under the debugger.

In this case, you have probably corrupted the heap before calling this function, either by writing off the end or off the start of a heap block.

回答3:

The easiest of approaches (provided that your application is not using memory too extensively) is to enable full page heap check (which will place so called guard page after the memory page your allocation is provided from, which, in turn, will pinpoint the exact place in your code where corruption takes place).

Given that you have Windows debugging tools handy, run the following gflags command to configure full page heap:

gflags[.exe] /p /enable yourapp.exe /full

Note, you should provide executable name alone (i.e. without path prefix!)
Then just run it under the debugger - it will break with the first attempt to corrupt the heap. The difference here is that heap corruptions are mostly delayed defects which manifest themselves later, when a (possibly) valid heap operation is in effect.

Note, also:

gflags[.exe] /p /enable yourapp.exe /full /backwards

will additionally place a guard page prior to your allocation.

Running with /p switch alone will display heap page options currently in effect.

回答4:

You may have a heap corruption bug. Your application may have corrupted the heap before open_new_log() is called.

回答5:

I suspect jmattias is right. The root cause of the problem is likely somewhere else than where it is crashing.

A lot of things can cause heap corruption.

• writing past the end (or beginning) of the memory block that was allocated.
• freeing a pointer twice, or freeing a pointer that wasn't allocated.
• multithreading your program and linking with the single-threaded (not thread safe) RTL.
• allocating memory from one heap and freeing it on another heap.
• etc., etc.,

Since you're using Visual C++, you can use the _CrtSetDbgFlag() feature of the debug heap to turn on error checking. You can set it to check the integrity of the heap on each call to malloc or free. That will run very slowly, but it should pinpoint where the bug is for you.

Search for _CrtSetDbgFlag in the compiler docs.

回答6:

I have a suspicion that there is a DLL compiled with a different version of the C++ runtime than the rest of the application. This will often result in "memory at address XXX could not be 'read'/'written'" violations.

文章来源: VC++ 6.0 access violation when run in debugger