views:

918

answers:

2

Hi, I have some code in MS VC++ 6.0 that I am debugging. For some reason, at this certain point where I am trying to delete some dynamically allocated memory, it breaks and I get a pop up message box saying "User Breakpoint called from code at blah blah".. then the Disassembly window pops up and I see

*memory address* int      3

The odd thing is, there is NOWHERE in the code that I am calling an assembly instruction like this (I think asm int 3 is a hardware break command for x86?)..

what could be causing this?

EDIT: ANSWER: My code was "walking off the end" of an array, but only in the locations marked by Visual Studio debug with 0xFDFDFDFD, which is called a NoMan'sLand fence.. I think its also called an Off-by-one error.. This array was unrelated to the point where i was freeing the memory when the error was occuring. Which made it harder to spot.. :(

+4  A: 

You're probably hitting code in the debug heap routines that have found heap corruption.

What does the call stack look like when you've hit the Int 3?

Edit: Based on the stack trace in your comments, the routine _CrtIsValidHeapPointer() is saying that the pointer being freed is bad. Here's the snippet of code from MSVC's DBGHEAP.C source:

    /*
     * If this ASSERT fails, a bad pointer has been passed in. It may be
     * totally bogus, or it may have been allocated from another heap.
     * The pointer MUST come from the 'local' heap.
     */
    _ASSERTE(_CrtIsValidHeapPointer(pUserData));

pUserData would be the value of the pointer you're deleteing.

Michael Burr
NTDLL! 7c90120e()NTDLL! 7c95d454()NTDLL! 7c96c5cf()NTDLL! 7c9603b0()KERNEL32! 7c85f8d7()
krebstar
_CrtIsValidHeapPointer(const void * 0x04880068) line 1697_free_dbg_lk(void * 0x04880068, int 1) line 1044 + 9 bytes_free_dbg(void * 0x04880068, int 1) line 1001 + 13 bytesoperator delete(void * 0x04880068) line 351 + 11 bytes
krebstar
Some thing like that...
krebstar
I think you need to get the Windows system DLL's symbols loaded. I don't think MSVC 6 supports that (but I may be wrong) - you might want to download Debugging Tools for Windows and use the WinDBG debugger: http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx
Michael Burr
Since it's breaking in _CrtIsValidHeapPointer(), you're likely to be freeing a pointer with a bogus value.
Michael Burr
Thanks for the link.. What does bogus value mean? Garbage, like, the pointer wasn't initialized in the first place? I'm pretty sure it was :(
krebstar
BTW, before it breaks, I get a message in the output window that says First-chance exception in XXXXX.exe (NTDLL.DLL): 0xC0000005: Access Violation. However this does not break and a few lines down the code is where it breaks..
krebstar
I'd say put a breakpoint on your delete call, then start tracing in the assembly - you can follow along with the runtime source in the VC98\CRT\SRC directory.
Michael Burr
I'm not too sure about tracing in assembly, I'm not too good with it yet.. But thanks :) I think I'll try to see if the pointer is valid.. :)
krebstar
Just make sure the value you're deleting is the same value you get from new. If so, make sure you're not deleting it more than once.
Michael Burr
I just checked it, and the pointer is valid. there is a memory address, and i can expound it to show its members.. The pointer in question is a pointer to a class.. There is only one created in my execution, and this is the only point where it is deleted :(
krebstar
Maybe show the code that creates the pointer - you're using the `new` operator to set the pointer?
Michael Burr
Is the memory the pointer is pointing to being allocated in one module (EXE or DLL) and freed in another?
Michael Burr
No, the memory is allocated and freed in the same module (DLL).. :( and yes, I am using "new".. it goes like.. pointer = new CustomClass(initializer);and is freed withdelete pointer;
krebstar
Hmm - I think you're going to have to step into the x86 assembly instructions to see what the runtime doesn't like (or you could compile the runtime to get source access to it - but I think that might possibly be more painful than wading through the assembly).
Michael Burr
Okay, thanks.. I'll update this when I get a solution :) Thanks..
krebstar
+1  A: 

(I think asm int 3 is a hardware break command for x86?

It is. It's called "hardware breakpoint". If you're using the VS debugger with the project source code, it's just like a breakpoint (but in the code). Since vs2005, if your application is launched without any debugger, the application will simply crash, like if it launched an unmanaged exception.

In lot of company, there is a simple macro used to add that breakpoint in the code. That can replace asserts and exceptions in some (hard and rare) cases :

#define BREAKPOINT __asm { int 3; }

BREAKPOINT;

See :

So i suggest looking for some Macro or object doing this, or maybe it appen in a module (dll/lib) that you don't have the code of?

Klaim
Yes there is some dll/lib that is opened in the program, and I don't have source code for it. However I do not think this is the cause.. Michael Burr's seems more likely.. Thanks anyway :)
krebstar